Opcode

Ana quiere pagar a Pedro. Su cartera prepara la transacción y las firmas necesarias; los nodos comprueban después si podía gastar esas monedas. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Un nodo es un programa que verifica transacciones y bloques y se comunica con otros participantes de la red. Bitcoin Script es el lenguaje de parte de esas comprobaciones. Un opcode es uno de sus pasos, como verificar una firma. Ana no escribe instrucciones a mano para un pago corriente. Pero un nodo no puede fiarse del nombre del propietario ni de una etiqueta que diga «firmado»: debe evaluar las condiciones. Un script válido es solo una parte de validar toda la transacción. [1] [4]

En un listado legible pueden aparecer OP_DUP u OP_CHECKSIG. Son nombres de instrucciones para las personas; dentro del script los representan códigos de un byte. El byte es una unidad habitual para medir datos. Otras partes contienen datos, como una clave pública. La clave pública sirve para verificar firmas y no tiene que mantenerse en secreto. Las instrucciones de la familia OP_PUSHDATA indican cuántos bytes siguientes deben introducirse como datos. Esos bytes no vuelven a ejecutarse como instrucciones. Piensa en la diferencia entre «añadir sal» en una receta y el ingrediente que echas al recipiente. [1] [2]

Imagina una pila de notas de la que retiras la de arriba. Así funciona la pila de trabajo básica del script. OP_DUP copia el elemento superior; OP_DROP lo elimina. Si ejecutas OP_DUP y después OP_DROP sobre una pila no vacía, recuperas su contenido inicial. No has duplicado monedas, solo datos de trabajo. Si falta un elemento necesario, la evaluación puede fallar. También importan el orden y la representación exacta de los datos. [1]

OP_EQUAL toma los dos elementos superiores, compara sus bytes y los sustituye por el resultado de la comparación. OP_EQUALVERIFY falla de inmediato si difieren; si coinciden, continúa sin dejar ese resultado en la pila. Ninguna de estas dos operaciones verifica por sí sola una firma. Cualquiera puede presentar dos copias iguales de una clave pública. Hace falta la comprobación de firma correspondiente para demostrar que alguien pudo firmar el mensaje requerido. [1] [4]

OP_CHECKSIG comprueba una firma frente a una clave pública y un mensaje construido a partir de la transacción, sin revelar la clave privada. La clave privada es un valor numérico secreto con el que se crea esa firma. El parámetro sighash determina qué partes cubre la firma; no todos los modos firman todo. Los scripts antiguos y SegWit versión 0 usan ECDSA, un algoritmo de firma. Tapscript, las reglas de scripts de Taproot, usa otro, Schnorr, con las claves habituales de 32 bytes. El nombre de la instrucción no basta sin ese contexto. [1] [3]

Una condición puede permitir un gasto normal o una vía alternativa de recuperación. OP_IF y OP_ELSE ayudan a elegir una rama según un valor de la pila; OP_ENDIF cierra la parte condicional. Bitcoin Script no tiene bucles generales que se repitan arbitrariamente. Eso no permite ignorar cualquier cosa en una rama no ejecutada. Algunas instrucciones se comprueban al leer el script: importan su tipo y la versión de las reglas. [1] [3]

CLTV, la instrucción OP_CHECKLOCKTIMEVERIFY, puede imponer un límite absoluto, como una altura de bloque determinada, la posición del bloque en la cadena. CSV, OP_CHECKSEQUENCEVERIFY, junto con las reglas de antigüedad, impone una espera relativa desde la confirmación de la salida gastada. Una salida es una cantidad recibida previamente con condiciones de gasto. Estas instrucciones comprueban campos de la transacción; no ponen en marcha un temporizador ni envían dinero, y tampoco sustituyen una firma. Cada aplicación debe combinar el bloqueo adecuado con sus demás condiciones. [7] [8] [9]

Antes de leer un ejemplo técnico, averigua si usa scripts antiguos, SegWit o Tapscript. Tapscript añade OP_CHECKSIGADD para combinar verificaciones de firmas. En cambio, OP_CHECKMULTISIG falla cuando se ejecuta; sus reglas lo ignoran en una rama no ejecutada. Los nombres no se contradicen: cambia el entorno de verificación. Una lista de opcodes no es una colección de piezas que puedan trasladarse sin más entre formatos. [1] [3] [6]

BIP 342 reserva la familia OP_SUCCESSx para futuras ampliaciones de Tapscript. Tras superar las comprobaciones previas, encontrar una de estas instrucciones al decodificar permite saltarse con éxito las comprobaciones posteriores del script, incluso en una rama no ejecutada. Un byte igual dentro de datos insertados no cuenta. Es un espacio para cambiar las reglas, no una protección nueva ya activada. Una condición basada en un significado futuro aún no definido puede no proteger los fondos como espera su autor. [1] [3]

Un Full Node comprueba las reglas de validez por sí mismo, pero puede aplicar condiciones más estrictas al aceptar y compartir transacciones sin confirmar. Por ejemplo, Bitcoin Core v29.0 rechaza por defecto la retransmisión de transacciones que usan una instrucción OP_SUCCESSx en Tapscript, aunque el consenso pueda admitirlas en un bloque. Al leer un ejemplo, identifica la versión, los datos iniciales, lo que cubre la firma y los casos de fallo. Una sintaxis legible no demuestra la seguridad de una cartera; normalmente confías este trabajo a software revisado. [1] [5]