Covenants y bóvedas: CTV, OP_CAT y el debate de 2026

Curiosidad

1. ¿Por qué una script estándar de Bitcoin puede verificar quién posee las claves, pero no a dónde van a parar las monedas?
2. ¿Qué restricciones específicas impone OP_CHECKTEMPLATEVERIFY a las transacciones futuras?
3. ¿Por qué volver a habilitar un único opcode de concatenación, mediante un soft fork, abriría la puerta a los covenants?

Explorar

Parte IPropuestas de pacto: CTV y OP_CAT

1. El script estándar de Bitcoin verifica la propiedad de una clave o hash, pero no puede restringir a dónde van las monedas después de desbloquearlas. Un covenant cambia esto al imponer condiciones en el `scriptPubKey` de las salidas descendientes. Este mecanismo se compara a menudo con vales de comida: a diferencia del efectivo, que puede gastarse en cualquier lugar, estos fondos están restringidos a restaurantes asociados específicos. Entre los usos propuestos se incluyen bóvedas con procesos de retiro diferidos, control de congestión y diseños más simples para Lightning.
2. Jeremy Rubin propuso OP_CHECKTEMPLATEVERIFY (CTV) en 2019. Este opcode incrusta un hash de un modelo de transacción futura dentro del UTXO actual. Para gastarlo, la propia transacción de gasto debe coincidir exactamente con este modelo; no se necesita firma en el paso de verificación. Esto fija el siguiente paso antes de ejecutar el actual. Cualquier desviación en las cantidades, destinos o estructura del script hace que la validación fracase inmediatamente, lo que garantiza un cumplimiento estricto del camino predefinido.
3. La limitación de CTV es su rigidez: los resultados de la transacción siguiente están fijados una vez que las monedas se bloquean, por lo que las comisiones deben gestionarse de otra manera, por ejemplo con un resultado de anclaje y el principio “hijo paga al padre”. A cambio, CTV es fácil de analizar y económico de validar.
4. OP_CAT, un opcode que concatena dos elementos de la pila, fue desactivado por Satoshi Nakamoto en 2010 como medida preventiva contra ataques de agotamiento de memoria. BIP347 propone volver a activarlo específicamente dentro del tapscript. Combinado con trucos de firma Schnorr, OP_CAT habilita covenants y otras lógicas complejas sin necesidad de nuevas reglas de consenso para cada caso de uso específico. Ofrece un bloque constructivo primitivo que los desarrolladores pueden combinar para crear restricciones personalizadas en transacciones futuras.
5. Las propuestas relacionadas incluyen OP_CHECKSIGFROMSTACK (BIP348), que verifica una firma sobre un mensaje arbitrario proporcionado en la pila en lugar de sobre la transacción de gasto. Esta flexibilidad, combinada con CTV (o, por separado, el propuesto ANYPREVOUT), permitiría canales Lightning simétricos en los que ninguna de las partes necesitaría almacenar datos de penalización para cada estado anterior del canal.
6. A fecha de 2026, ninguna de estas propuestas de covenants ha sido activada, aunque continúan los esfuerzos y argumentos a favor de su activación. El debate persiste sobre su utilidad, el riesgo que añaden a las reglas de consenso y el proceso de gobernanza necesario para su activación. La expansión de las reglas de consenso plantea cuestiones sobre la complejidad de la red y su mantenibilidad a largo plazo que siguen sin resolverse en la comunidad.

Parte IICovenants y bóvedas: el debate en 2026

7. Actualmente, los scripts de Bitcoin verifican condiciones sobre la transacción en curso, como las firmas o los timelocks. No pueden inspeccionar las salidas de la transacción que los gasta. Los covenants amplían este alcance: un scriptPubKey puede imponer restricciones sobre el scriptPubKey de las salidas creadas por la transacción que lo gasta. Esto limita a dónde pueden ir las monedas a continuación y habilita funciones como listas blancas de direcciones y canales de pago no interactivos.
8. BIP-119 propone OP_CHECKTEMPLATEVERIFY (CTV). Permite que un script incluya un hash de plantilla; la transacción de gasto debe coincidir con esta plantilla en sus salidas, cantidad de entradas, secuencias, tiempo de bloqueo y versión, aunque no en qué entradas se gastan. CTV es no recursivo, lo que significa que solo restringe el paso inmediato siguiente. Sustituye a OP_NOP4 y requiere un soft fork. Puede servir como base para “bóvedas”, las cuales añaden un retraso en la recuperación en caso de robo.
9. En una bóveda, los retiros deben pasar por un período de espera (por ejemplo, 12 horas) durante el cual una clave de recuperación independiente puede mover los fondos a un lugar seguro. Si un atacante roba la clave de uso diario e inicia un retiro, el propietario lo ve en la cadena y recupera los fondos antes de que termine el plazo. Así, el robo de la clave deja de ser una pérdida irreversible y pasa a ser un evento recuperable, siempre que la víctima vigile la cadena.
10. A pesar de las discusiones desde 2013, no se ha activado ningún soft fork de tipo covenant. Taproot (noviembre de 2021) sigue siendo la última gran actualización. En febrero de 2026 se publicó un cliente de activación para BIP-119 sin la participación de Bitcoin Core. Se requiere una señalización del 90% por parte de los mineros entre marzo de 2026 y marzo de 2027. Hasta mayo de 2026, la señalización seguía siendo prácticamente nula, lo que indica falta de consenso sobre su adopción.
11. OP_CAT (BIP-347) alcanzó su especificación completa en marzo de 2026, pero carece de parámetros de activación. Permite concatenar elementos de script, lo que hace posible una lógica más compleja que la de CTV por sí solo. CTV suele combinarse con CheckSigFromStack (CSFS), que verifica una firma sobre datos arbitrarios de la pila, no solo sobre la transacción de gasto. Juntos, aportan mejoras significativas de expresividad para los contratos inteligentes y el diseño de protocolos.
12. El debate gira en torno a contrapartidas: los covenants mejoran la seguridad y permiten nuevos protocolos como las bóvedas, pero introducen complejidad y riesgos de gobernanza. Un soft fork modifica las reglas de consenso, lo que requiere un amplio acuerdo de mineros y operadores de nodos. El estancamiento actual refleja la cautela ante posibles errores de implementación y la irreversibilidad de los cambios en el estado de la cadena. Los usuarios deben sopesar estos beneficios frente al riesgo de una activación fallida o disputada.

Datos clave

Ejercicio nueve, seis, tres, uno

Verificación de hechos

Fechas, cifras y afirmaciones verificadas con las fuentes publicadas que se enumeran a continuación.

• J. Rubin, OP_CHECKTEMPLATEVERIFY (BIP119), 2019-2020
• BIP347: OP_CAT in Tapscript (E. Heilman & A. Sabouri, 2023)
• BIP348: CHECKSIGFROMSTACK (B. Black & J. Rubin, 2024)
• Bitcoin Optech, 'Covenants' topic guide
• J. Rubin, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
• E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
• Delving Bitcoin activation discussions (2026)