OP_CHECKTEMPLATEVERIFY (OP_CTV): Cómo funciona el nuevo opcode para covenants en Bitcoin — Análisis técnico del BIP 119

La segunda entrega de la serie técnica sobre covenants de Cointelegraph Research explica el funcionamiento, aplicaciones y limitaciones de OP_CTV, propuesto por Jeremy Rubin en BIP 119.

OP_CHECKTEMPLATEVERIFY (OP_CTV) es un opcode propuesto por Jeremy Rubin en BIP 119 que permite definir condiciones de gasto mediante una estructura de template simple que incluye outputs, versión y locktime de la siguiente transacción. El opcode toma un hash de compromiso como argumento y verifica que cualquier transacción que lo ejecute incluya únicamente outputs que coincidan con dicho compromiso. Desde la creación de vaults hasta esquemas de control de congestión, OP_CTV representa un avance significativo hacia la implementación de covenants en Bitcoin, aunque mantiene ciertas rigideces propias de las transacciones pre-firmadas.

Fundamentos técnicos de OP_CTV según BIP 119

Propuesto por Jeremy Rubin en la Propuesta de Mejora de Bitcoin (BIP) 119, OP_CHECKTEMPLATEVERIFY es un opcode diseñado para crear estructuras de template para transacciones en la red Bitcoin. Su función principal es permitir que un script de bloqueo especifique de antemano los detalles de una transacción futura, restringiendo cómo pueden gastarse los fondos.

El template definido por OP_CTV puede incluir tres elementos fundamentales: los outputs de destino, la versión de la transacción y el locktime. El opcode opera sobre la pila (stack) de Bitcoin Script y espera recibir un hash de compromiso de 32 bytes como argumento para realizar la verificación.

Este artículo constituye la segunda parte de la serie técnica sobre covenants publicada por Cointelegraph Research, que examina las diferentes propuestas para implementar esta funcionalidad en Bitcoin.

Cómo ejecuta OP_CTV la verificación de templates

El proceso de ejecución de OP_CTV sigue una secuencia específica dentro del script de Bitcoin. En primer lugar, el opcode espera encontrar un hash de compromiso de 32 bytes en la parte superior de la pila. A continuación, calcula un StandardTemplateHash a partir de la transacción que se está ejecutando actualmente.

El StandardTemplateHash se genera serializando varios campos de la transacción: la versión, el locktime, el conteo de inputs y outputs, y el hash de todos los outputs, que compromete tanto los valores como los scriptPubKeys de destino. Finalmente, el opcode compara ambos hashes para verificar que coincidan.

El resultado de la verificación es binario: si los hashes coinciden, el opcode realiza un push de 1 a la pila, indicando éxito. Si no coinciden, realiza un push de 0, señalando un fallo en la verificación.

Estructura básica de un locking script con OP_CTV

Un ejemplo típico de script que utiliza OP_CTV sería el siguiente: <Commitment Hash> OP_CTV <PubKey> OP_CHECKSIG. Este script impone simultáneamente dos condiciones: que los detalles de la transacción coincidan con el template predefinido y que el gastador esté autorizado mediante la firma correspondiente a la clave pública especificada.

Implementación de ramificaciones (branching logic)

OP_CTV puede combinarse con los opcodes OP_IF y OP_ELSE para implementar lógica condicional que permita múltiples rutas de gasto. Un ejemplo de script con esta estructura sería: OP_IF <Hash_X> OP_CTV OP_ELSE <Hash_Y> OP_CTV OP_ENDIF.

En este esquema, el gastador selecciona una rama específica al construir la transacción. Una vez seleccionada la rama, OP_CTV verifica que la transacción coincida con el template correspondiente a ese hash. Cada hash de ruta se calcula a partir del conjunto completo de outputs y parámetros fijos definidos para esa transacción particular, lo que garantiza que no sea posible desviarse del plan de gasto preestablecido.

Caso de uso: Construcción de un vault Bitcoin con OP_CTV

Para comprender la aplicación práctica de OP_CTV, resulta útil examinar el caso hipotético de Alice, quien desea crear un vault, es decir, un UTXO con una política de gasto restringida. El objetivo de Alice es permitir retiros controlados con un mecanismo de seguridad que proteja sus fondos.

El vault de Alice contempla dos rutas de gasto posibles. La ruta normal permite enviar fondos a una hot wallet tras un retardo de 100 bloques, lo que proporciona tiempo suficiente para detectar y responder a cualquier actividad sospechosa. La ruta de emergencia, en cambio, permite el envío inmediato a cold storage si se detecta un compromiso de seguridad.

Estructura del vault

La implementación del vault requiere tres templates de transacción y dos ScriptPubKeys de OP_CTV. El primer template, denominado Tx_Unvault, es el único template posible para el UTXO del vault. El segundo, Tx_Hot, corresponde a la ruta normal e incorpora un retardo de 100 bloques utilizando OP_CHECKSEQUENCEVERIFY (CSV) a través del parámetro nSequence. El tercero, Tx_Cold, permite la ruta de emergencia sin ningún retardo.

El proceso de construcción comienza cuando Alice calcula un hash de compromiso CTV para cada uno de los tres templates. Posteriormente, construye el locking script del vault como un output P2WSH (Pay-to-Witness-Script-Hash).

El script del vault explicado

El script resultante, representado en la Figura 1 del artículo original de Cointelegraph Research, tiene la siguiente estructura:

OP_0 <sha256( OP_IF <100> OP_CHECKSEQUENCEVERIFY OP_DROP <Hash_Hot> OP_CHECKTEMPLATEVERIFY <Hot_PubKey> OP_CHECKSIG OP_ELSE <Hash_Cold> OP_CHECKTEMPLATEVERIFY <Cold_PubKey> OP_CHECKSIG OP_ENDIF )>

Este script codifica las dos rutas de gasto posibles, cada una con su propio hash de compromiso y clave pública asociada.

Funcionamiento del vault en la práctica

En la práctica, el vault opera de la siguiente manera. Para la ruta normal, Alice debe esperar 100 bloques después de intentar «desbloquear» los fondos. Luego construye la transacción Tx_Hot exactamente como fue precomprometida, la firma con su hot key correspondiente y utiliza OP_1 para seleccionar la primera rama del condicional.

Para la ruta de emergencia, la activación hacia cold storage es inmediata, sin necesidad de esperar ningún período de tiempo. Sin embargo, en ambos casos, la transacción debe coincidir exactamente con uno de los templates precomprometidos; cualquier desviación haría que la verificación fallara.

Es importante destacar que el conteo del timelock relativo no comienza hasta que se intenta «desbloquear» (unvault) los fondos, lo que significa que el período de espera solo se activa cuando el propietario inicia el proceso de retiro.

Ventajas y limitaciones de OP_CTV frente a transacciones pre-firmadas

OP_CTV guarda similitudes significativas con las transacciones pre-firmadas, una técnica existente que permite lograr restricciones similares mediante la firma previa de transacciones completas. Sin embargo, el nuevo opcode presenta ventajas importantes.

Entre las ventajas de OP_CTV se incluye la eliminación de la necesidad de generar y desechar claves efímeras, un proceso tedioso y propenso a errores en las transacciones pre-firmadas. Además, OP_CTV permite la reutilización de direcciones, ya que no se compromete con txids específicos, lo que reduce la complejidad operativa. El mecanismo resultante es más trust-minimized para construir vaults, esquemas de control de congestión y otros primitivos de contratos inteligentes.

No obstante, OP_CTV mantiene ciertas limitaciones. Persisten algunas rigideces propias de las transacciones pre-firmadas, como la imposibilidad de modificar dinámicamente los parámetros del template. Existe también un riesgo relacionado con el tamaño del UTXO: si el UTXO enviado a OP_CTV es demasiado pequeño, puede volverse inutilizable (unspendable), ya que las tarifas de transacción podrían superar su valor. Por el contrario, si el UTXO es demasiado grande, el exceso puede convertirse en una propina obligatoria para el minero, sin posibilidad de recuperación.

Una condición importante para el uso de OP_CTV es que una dirección que implemente este opcode puede reutilizarse siempre que se financie con la cantidad exacta requerida por el template de outputs, lo que impone restricciones adicionales en la gestión de fondos.

Adelanto del próximo artículo — SIGHASH_ANYPREVOUT (APO)

La serie técnica de Cointelegraph Research continuará en su próxima entrega con el análisis de SIGHASH_ANYPREVOUT (APO), otra propuesta ampliamente discutida para opcodes que implementan funcionalidad completa de covenants en Bitcoin. Esta propuesta representa un enfoque alternativo que podría ofrecer mayor flexibilidad que OP_CTV en determinados escenarios.

Los lectores interesados en profundizar en el tema pueden consultar la primera parte de la serie, disponible en los archivos de Cointelegraph, que establece los fundamentos teóricos de los covenants y su importancia para el desarrollo futuro de Bitcoin.