Decodificación del Script de Bitcoin: El Lenguaje de Programación Detrás del Dinero Digital

Introducción

Bitcoin a menudo se refiere como dinero programable. Su naturaleza digital brinda a los usuarios una mayor flexibilidad para definir las condiciones de uso de sus fondos.

Al discutir sobre Bitcoin, las conversaciones típicamente giran en torno a las billeteras y las monedas. Sin embargo, una conceptualización más precisa sería pensar en las billeteras como llaves, las monedas como cheques y la blockchain como un vault seguro. Cada vault presenta una abertura estrecha por la cual se pueden insertar cheques o examinar los contenidos. El acceso al vault en sí permanece restringido a aquellos que poseen la llave correcta.

Cuando un titular de la clave desea transferir fondos, desbloquea la bóveda. Este proceso implica crear un nuevo cheque que hace referencia al original ( que se invalida ) y asegurarla en una bóveda accesible solo para el destinatario previsto. El nuevo destinatario sigue pasos idénticos al gastar estos fondos.

Este artículo examina Bitcoin Script - el lenguaje de programación que los nodos de la red Bitcoin utilizan para controlar los mecanismos de bloqueo y desbloqueo de estos cofres digitales.

La mecánica de las transacciones de Bitcoin

Siguiendo nuestra analogía, cada transacción de Bitcoin consta de dos componentes esenciales: una llave (para el acceso a la bóveda) y un candado. La llave desbloquea la bóveda que contiene el cheque que deseas transferir, mientras que el nuevo cheque se coloca en otra bóveda asegurada con un candado diferente. Acceder a los fondos de esta nueva bóveda requiere otra llave específica.

Este sistema ofrece una flexibilidad notable. La red admite varios tipos de bloqueo: algunos cofres pueden requerir múltiples llaves, otros pueden exigir prueba de autoridad para el acceso. Los usuarios pueden personalizar numerosas condiciones según sus requisitos específicos.

En términos técnicos, la clave se denomina scriptSig, mientras que el bloqueo se llama scriptPubKey. Al examinar más de cerca, estos componentes se revelan como combinaciones de fragmentos de datos y bloques de código que en conjunto forman un programa compacto.

Durante la ejecución de la transacción, esta combinación se propaga a través de la red. Cada nodo receptor verifica la validez de la transacción. La verificación fallida resulta en fondos inaccesibles.

Los cheques (coins) son técnicamente conocidos como salidas de transacción no gastadas (UTXOs). Cualquier usuario que posea una clave apropiada puede utilizar estos fondos. Específicamente, scriptSig funciona como la clave mientras que scriptPubKey actúa como el candado.

Si su billetera contiene UTXOs, es probable que contengan una condición que estipula que solo las personas que pueden demostrar la propiedad de una clave pública en particular pueden desbloquear los fondos asociados. Para desbloquearlos, debe proporcionar un scriptSig firmado digitalmente con una clave privada correspondiente a la clave pública especificada en scriptPubKey.

Fundamentos de Bitcoin Stack

El script opera como un lenguaje basado en pilas. Las instrucciones se organizan en una columna vertical, comenzando la ejecución desde el elemento superior. Por ejemplo, los elementos A, B y C forman una pila con C en la parte superior y A en la parte inferior. Al ejecutar instrucciones, las operaciones comienzan con los elementos de la parte superior de la pila.

Los elementos se agregan y se "sacan" de la pila durante la ejecución.

Los elementos de datos (, como firmas, hashes y claves públicas ), difieren de las instrucciones ( o códigos de operación ). Las instrucciones eliminan datos y realizan operaciones sobre ellos. Considera este ejemplo simplificado:

Los datos aparecen en rojo, los códigos de operación en azul. Leyendo de izquierda a derecha, la cadena primero entra en la pila. El código de operación (hipotético para este ejemplo) luego elimina el elemento superior de la pila () y aplica el hash MD5, empujando el resultado de nuevo a la pila: d16fb36f0911f878998c136191af705e.

A continuación, entra en la pila, lo que resulta en dos elementos idénticos. Finalmente, elimina los dos elementos superiores y los compara, empujando <1> en la pila si son idénticos o <0> si son diferentes.

Al llegar al final de la lista de instrucciones, la validación del script sigue dos reglas: se produce un fallo si el elemento restante es nulo o si una instrucción falla debido a condiciones no cumplidas. En este ejemplo, ninguna de las condiciones se aplica: tenemos un elemento no nulo (<1>), confirmando la validez del script. Estas mismas reglas rigen las transacciones reales de Bitcoin.

Pago-a-Pubkey (P2PK)

Pay-to-Pubkey (P2PK) representa la forma de transacción más elemental. Bloquea fondos a una clave pública específica. Para recibir fondos a través de este método, los destinatarios deben proporcionar a los remitentes su clave pública en lugar de una dirección de Bitcoin.

La primera transacción entre Satoshi Nakamoto y Hal Finney en 2009 utilizó P2PK. Esta estructura era común en los primeros días de Bitcoin, pero ha sido en gran medida reemplazada por Pay-to-Pubkey-Hash (P2PKH).

El script de bloqueo para P2PK sigue el formato sencillo: OP_CHECKSIG. Como su nombre indica, OP_CHECKSIG verifica la firma con la clave pública proporcionada. El scriptSig correspondiente simplemente contiene .

El proceso de ejecución no podría ser más sencillo: la firma entra en la pila, seguida de la clave pública. OP_CHECKSIG examina ambos elementos y verifica la firma contra la clave pública. Una coincidencia resulta en <1> siendo añadida a la pila; de lo contrario, aparece <0>.

P2PK ha caído en desuso, con razones exploradas en la siguiente sección.

Pagar-a-Pubkey-Hash (P2PKH)

Pay-to-Pubkey-Hash (P2PKH) representa el tipo de transacción más prevalente en la red de Bitcoin. El software de billetera moderno típicamente implementa este formato por defecto.

El scriptPubKey P2PKH sigue esta estructura:

OP_DUP OP_HASH160 <clave pública="" hash=""> OP_EQUALVERIFY OP_CHECKSIG

Antes de examinar el scriptSig correspondiente, entendamos los opcodes involucrados:

OP_DUP

OP_DUP elimina el elemento superior, crea un duplicado y empuja ambas versiones de vuelta a la pila. Esto permite realizar operaciones en la copia mientras se preserva el original.

OP_HASH160

Este opcode elimina el elemento superior y aplica un hashing dual: primero SHA-256, luego RIPEMD-160 a la salida de SHA-256. El hash resultante regresa a la pila.

OP_EQUALVERIFY

OP_EQUALVERIFY combina dos operaciones: OP_EQUAL y OP_VERIFY. OP_EQUAL elimina dos elementos y verifica su identidad, empujando \u003c1\u003e si son idénticos o \u003c0\u003e si son diferentes. OP_VERIFY elimina el elemento superior y verifica su valor de verdad (no nulo). Combinado como OP_EQUALVERIFY, esto causa un fallo en la transacción si los dos elementos superiores no coinciden.

La estructura correspondiente de scriptSig es:

Desbloquear salidas P2PKH requiere proporcionar tanto una firma válida como su clave pública correspondiente.

Este proceso se basa en el flujo de ejecución P2PK, añadiendo una verificación de que la clave pública proporcionada coincide con el hash incrustado en el script.

Una distinción importante: en los scripts de bloqueo P2PKH, la clave pública permanece oculta - solo aparece su hash. Examinar una salida P2PKH no gastada en exploradores de blockchain no revela información de la clave pública. La clave se vuelve visible solo cuando el destinatario transfiere los fondos.

Este enfoque ofrece varias ventajas. Primero, los hashes de claves públicas permiten una transmisión más compacta que las claves públicas completas; esto motivó la implementación de Satoshi en 2009. Estos hashes de claves públicas constituyen las direcciones de Bitcoin que los usuarios intercambian.

En segundo lugar, el hash de la clave pública introduce una capa de seguridad adicional contra las amenazas de la computación cuántica. Dado que la clave pública permanece oculta hasta que ocurre el gasto, determinar la clave privada correspondiente se vuelve significativamente más desafiante. Cualquier ataque requeriría revertir dos operaciones de hash consecutivas (RIPEMD-160 y SHA-256).