Bitcoin Script

Alice recibe 20 000 sat, veinte mil de las unidades más pequeñas de bitcoin. La red no abre una cuenta a su nombre: crea una salida de transacción, una cantidad junto con la condición para gastarla después. Mientras no se gaste, se llama UTXO. En un pago habitual, la condición exige una firma con la clave correspondiente. Cuando Alice paga más adelante, su cartera selecciona esa salida, la referencia mediante una nueva entrada de transacción y crea una firma digital. Para ello utiliza la clave privada sin enviarla a ninguna parte; los demás verifican la firma con la clave pública. Conocer la dirección de recepción de Alice no basta. Las condiciones de la salida original se guardan en el campo scriptPubKey, y Bitcoin Script establece cómo comprobar que se cumplen. Un nodo no es un funcionario que reconoce a Alice: es un ordenador que comprueba reglas. Además de verificar la firma, debe comprobar, por ejemplo, que esa misma salida no se haya gastado ya. La transacción solo es válida cuando satisface todas las reglas aplicables. [4] [2]

En los pagos corrientes, la cartera construye las condiciones. Siga sus instrucciones de copia de seguridad: una recuperación normal mediante palabras en una cartera compatible no exige automáticamente guardar cada script a mano. En una configuración más compleja, como Multisig, que requiere varias firmas, las palabras de un solo participante quizá no describan todo el mecanismo de gasto. Para el uso habitual conviene recurrir a una cartera con procedimientos contrastados, en lugar de construir scripts a mano en notación hexadecimal. Los descriptores de salida describen el tipo de script, las claves y su derivación, y ayudan a determinar qué debe buscar una cartera restaurada. La clave privada por sí sola puede no bastar para recuperar una configuración más compleja. Conviene conservar también los scripts necesarios y los datos de origen de las claves, es decir, de dónde y cómo se derivaron, y verificar las vías de gasto previstas. [11]

Los capítulos siguientes muestran cómo se codifican las condiciones dentro de la transacción; no necesita conocer estos detalles para pagar normalmente. El campo scriptSig y la parte llamada witness aportan datos de verificación. Un hash es una huella de los datos, y un bloqueo temporal impide gastar antes de un umbral determinado. Puede imaginar la pila como un montón de elementos que se manipulan desde arriba. Script procesa los datos mediante una pila: coloca valores en ella y las instrucciones, llamadas opcodes, los extraen, comparan o procesan de otras formas. Las instrucciones de firma verifican firmas; ni las claves privadas ni la creación de firmas forman parte de esa verificación. El lenguaje permite combinar firmas, condiciones basadas en hashes y bloqueos temporales. No tiene bucles de propósito general y no es Turing completo: no permite expresar cualquier cálculo que pueda realizar un lenguaje de programación universal. El nodo debe aplicar las reglas exactas que correspondan al tipo de salida y a la versión del script. [1] [3]

En P2PKH (Pay to Public Key Hash), la salida suele tener la forma OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. La entrada aporta una firma y una clave pública en su scriptSig. La verificación comprueba que el hash de la clave pública coincide con el valor de la salida y, a continuación, verifica la firma. Por eso, conocer la dirección o la clave pública no basta para realizar ese gasto. La clave privada la utiliza la cartera que firma, no el nodo que comprueba la transacción. [1]

P2SH, definido en BIP16, guarda en la salida el hash de un script. La entrada que la gasta aporta el redeemScript correspondiente, es decir, el script que se revela al gastar, junto con los datos necesarios. Su scriptSig solo puede contener instrucciones que introduzcan datos en la pila. El nodo comprueba primero que el hash coincide y después evalúa el redeemScript con los elementos restantes de la pila. Un hash correcto no basta por sí solo: también deben cumplirse las condiciones de ese script. [5]

En SegWit versión 0, los datos de verificación se trasladan a la parte de la transacción llamada witness. Esta es una lista de elementos de datos, no un script en sí misma. P2WPKH utiliza una firma y una clave pública; P2WSH incluye además un witnessScript cuyo hash SHA256 debe coincidir con la salida. En SegWit nativo, scriptSig está vacío. Cuando se encapsula en P2SH, solo contiene la instrucción que introduce el programa witness correspondiente; los datos de verificación siguen en witness. [6]

La verificación de una firma utiliza un mensaje derivado de la transacción mediante un procedimiento definido. El modo SIGHASH determina qué partes quedan protegidas frente a modificaciones por esa firma. Por tanto, no se puede afirmar que toda firma cubra siempre la transacción entera. En las operaciones de firma de SegWit versión 0, BIP143 incluye siempre el importe de la salida que se gasta. La cartera debe conocer los datos correctos y el modo elegido; al verificar, Script no interpreta la intención humana de quien firma. [7]

Taproot, definido en BIP341, permite gastar una salida P2TR (Pay to Taproot) de dos maneras. La vía de la clave verifica una firma Schnorr con la clave pública de la salida, sin revelar un script. La vía del script revela, en cambio, el script elegido y un bloque de control, llamado control block, que demuestra su vinculación con la salida. No es necesario revelar los demás scripts del árbol. Las reglas aplicables al script revelado también dependen de la versión de la hoja correspondiente. [8]

BIP342 define Tapscript para las hojas de Taproot de versión 0xc0. Aquí las instrucciones de firma utilizan firmas Schnorr, y OP_CHECKSIGADD permite construir una condición que exija varias firmas. La antigua instrucción OP_CHECKMULTISIG está deshabilitada: si se ejecuta, la validación falla. No se heredan el límite anterior de 10 000 bytes por script ni el de 201 opcodes contabilizados según las reglas antiguas. Las operaciones de firma están limitadas por un presupuesto calculado a partir del tamaño de witness; siguen existiendo límites para la pila. Por ello, los límites de una versión no deben presentarse como propiedades generales de todo Script. [9]

Las reglas de consenso determinan si un gasto es válido dentro de un bloque. La condición de estándar, o standardness, se refiere a las reglas locales adicionales de un nodo para admitir transacciones sin confirmar en su Mempool y retransmitirlas; no es un proceso de estandarización. Una transacción válida según el consenso puede, por tanto, no retransmitirse de forma habitual. OP_SUCCESSx exige especial atención en Tapscript: una vez superadas las comprobaciones previas, su reconocimiento durante la decodificación hace que la verificación del script termine con éxito, antes de la ejecución normal y de las comprobaciones de la pila. Es un mecanismo reservado para futuras ampliaciones, no una condición de gasto segura para el uso corriente. [10] [9]