OP_CHECKTEMPLATEVERIFY es una instrucción propuesta para Bitcoin Script, el lenguaje con el que se expresan las condiciones para gastar bitcoins. Comprobaría que ciertos datos de la transacción coincidan con un plan previo: una plantilla. El plan se representa mediante una breve huella criptográfica llamada hash. No es una firma ni una huella de toda la transacción; BIP119 define exactamente qué abarca.
Anna quiere reservar fondos para repartirlos más adelante entre Peter y Eva. No quiere depender únicamente de la promesa de alguien que custodie el dinero. En Bitcoin, los fondos sin gastar se registran como salidas de transacciones, llamadas UTXO: cada una contiene un importe y las condiciones para utilizarlo. CTV podría incorporar un plan concreto de reparto a esas condiciones. Al gastar la salida, los nodos —programas que comprueban las reglas de la red— verificarían que la nueva transacción respete el plan. Otro destinatario o un importe distinto del fijado no superarían la comprobación. Jeremy Rubin describe esta propuesta en BIP119, cuyo número BIP se asignó en 2020. [1] [3]
La plantilla determina la estructura de la transferencia: a cuántas salidas anteriores hacen referencia las entradas y qué nuevas salidas deben crearse. En estas últimas fija los importes y los scripts, es decir, las condiciones para gastarlas después. Más en detalle, BIP119 incluye la versión de la transacción; nLockTime, un campo para restricciones temporales de toda la transacción; los campos nSequence de las entradas, que pueden afectar a los bloqueos temporales; y el índice de la entrada que se está comprobando. Si algún scriptSig, un script de entrada con datos para el gasto, no está vacío, también se incorpora un hash de todos los campos scriptSig. No es solo una lista de destinatarios: cambiar cualquier otro dato incluido produce otra plantilla. Las referencias a las monedas anteriores concretas y sus importes son una cuestión distinta, que veremos más abajo. [1]
El byte es una unidad habitual para medir datos. La comprobación propuesta utiliza un hash de plantilla de 32 bytes calculado con SHA256. El nodo obtiene la misma huella de la transacción que gasta la salida y rechaza cualquier discrepancia. Una firma digital acredita la autorización de un pago mediante una clave privada, un valor numérico secreto, sin revelar esa clave. Otra parte del script puede exigir una firma; CTV no la sustituye en todos los casos. Otras longitudes de argumento no realizan esta comprobación y se reservan para futuras ampliaciones, aunque la política de retransmisión puede rechazarlas. Un argumento incorrecto no garantiza un bloqueo seguro. [1] [4] [12]
En el siguiente ejemplo usamos sats, las unidades más pequeñas de bitcoin. El hash de la plantilla no incluye directamente los outpoints, es decir, las referencias a las UTXO concretas gastadas, ni sus importes de entrada. Sí fija el número de entradas. Supongamos una sola entrada permitida y salidas que suman 99 000 sats. Una entrada de 100 000 sats deja 1 000 sats como comisión. Una entrada inferior al total de las salidas no puede financiar la transacción. Si es mayor y las salidas no cambian, aumenta la comisión; no se crea cambio automáticamente. [6] [9]
La plantilla puede exigir pasar a otra salida cuyo script incluya una demora y una vía de recuperación. Así se puede construir una bóveda con tiempo para reaccionar a una retirada no deseada. CTV no constituye toda la seguridad: importan las claves, las condiciones posteriores, la vigilancia y la confirmación a tiempo de la recuperación. Algunas restricciones pueden prepararse con transacciones prefirmadas, pero requieren otras formas de cooperación y eliminación de claves. [8] [5]
Un bloque agrupa transacciones en un lote que se añade al historial compartido. En el control de congestión propuesto se confirma primero una salida que compromete los fondos a una distribución posterior. Las salidas individuales de los destinatarios pueden aparecer en transacciones siguientes, quizá cuando la red esté menos ocupada. Los destinatarios necesitan conocer el plan y poder ejercer su derecho. Eso difiere de un pago ordinario ya confirmado a su dirección y no convierte un bloque limitado en espacio infinito. [7] [11]
Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. Anna puede preparar el plan mucho antes de publicar el pago, sin conocer todavía las comisiones futuras. Las salidas fijas no le permiten reducir libremente el importe que vuelve a su cartera y ofrecer la diferencia al minero. La construcción necesita, por tanto, un modo de añadir comisión. Una opción es un CPFP preparado adecuadamente: una transacción posterior gasta una salida de la original y ofrece una comisión que incentive al minero a incluir ambas. Otra opción es una plantilla que ya contemple una entrada adicional desde el principio. No se puede añadir esa entrada sin más a una plantilla que permita solo una. El mempool es el conjunto de transacciones sin confirmar de un nodo concreto; entrar en él no garantiza aparecer en un bloque. [2] [6] [10]
CTV por sí solo comprueba una plantilla concreta; no es un lenguaje general para leer y comparar arbitrariamente todos los datos de la transacción. Permite preparar planes ramificados de transacciones futuras, pero no debe confundirse con Covenants recursivos generales. Combinado con otras instrucciones propuestas podría hacer más. Conviene comprobar si una demostración usa solo CTV o todo un conjunto de cambios. [1] [2]
En la revisión del 17 de octubre de 2026, BIP119 tiene estado Draft, es decir, sigue siendo una propuesta en desarrollo. Daría una nueva función de comprobación a OP_NOP4, una instrucción que hoy no tiene efecto durante la validación de bloques. Ese endurecimiento de las reglas compartidas se llama Soft Fork. Sin embargo, el documento no define por sí mismo la activación. Publicar un BIP no convierte el opcode en una instrucción aplicada por la red; tampoco el código, el apoyo de un desarrollador o una cartera de demostración prueban su aplicación en la red principal de Bitcoin, mainnet. En cualquier demostración hay que identificar la red, las reglas y las demás propuestas de las que depende. [1]
Mientras la regla no se aplique, incluirla en un script no proporciona por sí solo la protección esperada: consenso y rechazo del mempool son distintos. Incluso con CTV, una única plantilla obligatoria sin vía alternativa puede atrapar una salida con fondos insuficientes. Un nuevo depósito pequeño no bloquea automáticamente otras UTXO correctamente financiadas. Un diseño seguro debe comprobar importes, comisiones, copias de seguridad y todas las vías de recuperación. [1] [4] [6]
Para obtener la imagen más completa, lee esta entrada junto con Covenants, Timelock, Reglas de consenso, Bitcoin Script, UTXO, CPFP (Child Pays for Parent). También enlazan con esta entrada Covenants, Bitcoin Vault, OP_CAT, Ark.