Glosario / Referencia para desarrolladores
OP_CHECKSIG
- ¿Qué es OP_CHECKSIG?
- OP_CHECKSIG desapila una clave pública y una firma, y verifica que la firma cubre esta transacción: es la verificación que realmente demuestra la propiedad de las monedas.
Casi todos los bitcoin que se han gastado han pasado por este único opcode (código de operación), el byte 0xac. Calcula un hash de la transacción según el byte del indicador de sighash pegado al final de la firma, verifica la firma con la clave pública y apila verdadero o falso. Si apila falso, el gasto no se produce, y eso es todo lo que significa, en código, ser dueño de bitcoin.
Cómo funciona
OP_CHECKSIG desapila dos elementos, primero la clave pública y después la firma que está debajo, y luego realiza tres tareas distintas que se suelen reducir a una sola.
Primero decide qué se firmó. El último byte de una firma no forma parte de la firma: es un indicador que dice qué partes de la transacción cubría el hash. El valor abrumadoramente más común es 0x01, que significa todas las entradas y todas las salidas, así que alterar cualquier parte de la transacción después de firmarla la invalida. La receta para construir ese hash se ha reemplazado dos veces, con el BIP-143 para los gastos de SegWit versión 0 y de nuevo con el BIP-341 para Taproot, ambas veces para evitar que el costo de calcular el hash creciera con el cuadrado del tamaño de la transacción.
En segundo lugar, comprueba la codificación, y bitcoin es inusualmente estricto en esto. Una firma heredada (legacy) debe estar codificada en DER válido, con 72 bytes como máximo incluido el byte del indicador, y con el valor S en la mitad inferior del orden de la curva. La regla de codificación estricta llegó con el BIP-66 en julio de 2015, y la transición dejó huérfanos seis bloques en una sola tarde porque varios grandes pools de minería construían sobre encabezados de bloque que no habían validado. Sigue siendo la demostración más clara de que minar y validar son tareas distintas.
En tercer lugar, verifica. Los gastos heredados y los de SegWit versión 0 usan ECDSA sobre secp256k1. Tapscript usa en su lugar una firma Schnorr de 64 bytes según el BIP-340, exige que una verificación fallida apile un elemento vacío y no cualquier otra cosa, y descuenta 50 unidades de peso del presupuesto del script por cada firma verificada.
Dónde aparece
OP_CHECKSIG cierra casi todos los scripts que existen. Una salida heredada termina con él, un gasto SegWit nativo de una sola clave ejecuta la misma plantilla con el mismo opcode final aunque esos bytes nunca aparezcan en la cadena, y los scripts de compromiso de Lightning terminan con él después de sus ramas de bloqueo temporal (timelock) y de revocación.
Conviene conocer la excepción al consultar un explorador de bloques. Un gasto por ruta de clave de Taproot no ejecuta ningún script: el nodo verifica una sola firma directamente con la clave de 32 bytes de la salida. No hay representación en ensamblador (ASM) que mostrar ni opcode que señalar, y precisamente por eso ese tipo de gasto es el más barato y el más privado que existe, y por eso una dirección que empieza por bc1p y que solo gasta su dueño se ve idéntica on-chain a cualquier otra.
OP_CHECKSIG frente a OP_CHECKSIGADD
El opcode OP_CHECKSIGADD existe porque OP_CHECKSIG no se puede contar. En un script de varias partes hay que saber cuántas de las firmas presentadas eran válidas, y el diseño antiguo lo resolvía con un único opcode que se tragaba de una vez toda una lista de claves y firmas. Tapscript lo reemplazó por un opcode que verifica una firma y suma uno a un total acumulado en la pila, de modo que una política de 2 de 3 se convierte en una secuencia corta que termina en una comparación con 2. El cambio no es cosmético: contar las firmas de una en una es lo que permite verificar las firmas Schnorr por lotes, y de la verificación por lotes sale la velocidad de validación de Taproot.