Glosario / Protocolo y actualizaciones
OP_CHECKTEMPLATEVERIFY
También se conoce como CTV o BIP119.
- ¿Qué es OP_CHECKTEMPLATEVERIFY?
- OP_CHECKTEMPLATEVERIFY es un opcode (código de operación) propuesto que permitiría que una salida fije de antemano la transacción exacta que puede gastarla, hasta sus salidas y sus montos.
Se especifica en el BIP-119.
Lo describe BIP-119, Jeremy Rubin publicó el primer borrador en enero de 2020 y la red no lo ha adoptado. El opcode tomaría un hash de 32 bytes de la pila y haría fallar el script salvo que coincidiera un hash de la plantilla de la transacción que gasta, es decir, de su versión, su locktime, su número de entradas, sus números de secuencia, sus salidas y el índice de la entrada. Nada en su billetera lo usa, ni lo usará hasta que se active una bifurcación blanda (soft fork).
Cómo funciona
Estado: propuesto, no activado. BIP-119 es un borrador desde 2020, una activación propuesta en 2022 suscitó objeciones suficientes para quedar archivada, y Bitcoin Core no contiene parámetros de despliegue para él.
El diseño reutiliza un viejo truco de actualización. El opcode 179, antes OP_NOP4, actualmente no hace nada en absoluto, así que un script que lo contiene es válido para todos los nodos de la red. Una bifurcación blanda redefiniría ese byte para que los nodos actualizados hicieran la comprobación mientras los no actualizados seguirían dejando pasar el script, la misma ruta que siguió CLTV con OP_NOP2 y CSV con OP_NOP3.
Lo que entra en el hash se elige con un cuidado poco habitual. La plantilla incluye las salidas, los montos, el número de entradas y sus números de secuencia, pero deja fuera deliberadamente los outpoints, es decir, los txid de las monedas que se gastan. Dejarlos fuera tiene dos consecuencias sobre las que descansa toda la propuesta. Primero, se puede calcular el hash antes de que exista la transacción de financiación, y eso es lo que permite construir una cadena de gastos futuros y luego financiarla. Segundo, una plantilla no puede contener un compromiso consigo misma, así que no se puede hacer que la restricción se repita para siempre, y por eso sus partidarios lo llaman el covenant estrecho (un covenant es una restricción sobre cómo se puede gastar una moneda).
El resultado es un gasto cuyo txid se conoce antes de que ocurra. Una billetera puede entregarle un recibo de un pago que existirá más adelante y demostrar que no es posible ningún otro gasto de esa moneda.
Dónde aparece
OP_CHECKTEMPLATEVERIFY no se ejecuta en ningún lugar de la mainnet, así que el lugar donde mirar es el conjunto de aplicaciones construidas sobre signets personalizadas que se lanzarían si el opcode se activara.
El control de congestión es la aplicación más citada. Un exchange que se enfrenta a un pico de comisiones paga 1.000 retiros en una sola salida que fija un árbol de pagos posteriores; cada usuario puede después expandir su propia rama y recibir sus monedas cuando bajen las comisiones, y el exchange ha gastado una salida en lugar de mil. Las bóvedas son la segunda: un retiro debe llegar primero a una salida intermedia con un retraso, lo que le da a usted un plazo para devolver los fondos al almacenamiento en frío si la solicitud no era suya. Los pools de pagos y la financiación no interactiva de canales Lightning usan la misma forma de fijar primero y expandir después.
Para quien compra bitcoin, la postura honesta es que esto no cambia nada que usted pueda poner en práctica. Vale la pena reconocer la sigla porque aparece constantemente en los debates sobre en qué debería convertirse bitcoin, y porque las funcionalidades de bóveda que anuncian algunos servicios de custodia se podrían hacer cumplir de verdad si alguna vez se activara.
OP_CHECKTEMPLATEVERIFY frente a OP_CHECKLOCKTIMEVERIFY
OP_CHECKTEMPLATEVERIFY restringe la forma de la transacción que gasta, mientras que OP_CHECKLOCKTIMEVERIFY restringe cuándo puede producirse un gasto y no dice nada sobre adónde va el dinero. Por sus nombres casi idénticos, los dos se confunden constantemente.
La otra diferencia es el estado, y es la que importa. OP_CHECKLOCKTIMEVERIFY está en vigor desde el bloque 388.381, el 14 de diciembre de 2015, y lo usan a diario Lightning, los scripts de escrow (depósito en garantía) y las billeteras de herencia. Ni un solo nodo de la mainnet ha hecho cumplir nunca OP_CHECKTEMPLATEVERIFY. Si un servicio le dice que sus monedas están protegidas por un compromiso de plantilla, está describiendo algo que la red actualmente no comprueba.