La frontera criptográfica: witness encryption y PIPEs

Curiosidad

1. ¿Por qué Bitcoin puede verificar una firma pero no restringir a dónde irá la moneda resultante a continuación?
2. ¿Cuánto cuesta demostrar que conoces un secreto sin revelar el secreto en sí?
3. ¿Cómo mantienen los protocolos la seguridad cuando las reglas subyacentes permanecen estáticas e inmutables?

Explorar

Parte ILa frontera criptográfica: covenants y cifrado de testigo

1. El Script de Bitcoin está deliberadamente limitado. Puede verificar que una firma coincida con una clave pública, pero no puede inspeccionar el destino de las monedas una vez gastadas. Esta restricción mantiene al Script simple y predecible. Sin embargo, también impide ciertos diseños en los que las condiciones de gasto dependen de estructuras de transacciones futuras.
2. La propuesta de Jeremy Rubin de OP_CHECKTEMPLATEVERIFY (BIP-119) aborda esta carencia. El opcode permitiría que un script exigiera que la transacción de gasto coincidiera con una plantilla comprometida, fijando sus salidas y algunos otros campos. Esto habilita covenants no recursivos: reglas sobre adónde pueden ir las monedas a continuación, como bloquear fondos en bóvedas o restringir las vías de canje. Aún no se ha activado y sigue siendo objeto de debate en la comunidad de Bitcoin.
3. Una propuesta distinta, OP_CAT (BIP-347), se centra en concatenar datos en la pila en lugar de imponer directamente restricciones de destino, aunque, combinada con las firmas Schnorr, también puede habilitar covenants. Esta operación sencilla permite construcciones criptográficas complejas, como las firmas en árbol, que expresan de forma compacta políticas multifirma muy extensas. También facilita las firmas Lamport, resistentes a la computación cuántica, al permitir manipular hashes y valores directamente dentro del motor de scripts.
4. Más allá de los nuevos opcodes, la investigación explora el cifrado de testigo como una vía alternativa hacia la programabilidad. El cifrado de testigo permite a un remitente bloquear datos de modo que solo quien pueda demostrar que posee un secreto específico (un testigo) pueda desbloquearlos. En teoría, esto podría permitir que las claves de bitcoin se revelen únicamente tras la prueba de una afirmación, sin necesidad de que la red verifique directamente el cálculo.
5. Existen construcciones iniciales de cifrado de testigo en la literatura académica, pero siguen siendo poco prácticas para su despliegue en Bitcoin. Todavía no existe una construcción práctica para afirmaciones generales: los esquemas conocidos son enormes y se basan en supuestos criptográficos que aún no gozan de amplia confianza. Aunque las bases teóricas son sólidas, la brecha de ingeniería entre una prueba de concepto y un protocolo listo para producción sigue siendo considerable.
6. El compromiso es claro: los covenants aportan expresividad, pero introducen nuevas reglas de consenso que requieren una revisión cuidadosa; el cifrado de testigo aporta privacidad y flexibilidad, pero impone altos costos de almacenamiento y cálculo. Ambos enfoques buscan ampliar las capacidades de Bitcoin sin abandonar su modelo de seguridad fundamental de emisión fija y predecible y de capacidad de scripting limitada.

Parte IIMeter y sacar bitcoin: PIPEs y cifrado de testigos

7. Shielded Bitcoin, explicado en la lección anterior, gestiona las transferencias privadas dentro de su propio sistema de notas. Deja fuera del alcance el peg-in y el peg-out: cómo mover valor desde el Bitcoin ordinario y transparente hacia la capa blindada, y de vuelta. El plan de diseño para estos puentes se basa en un mecanismo llamado cifrado de testigos (witness encryption), en concreto Bitcoin PIPEs v2 (IACR ePrint 2026/186, febrero de 2026).
8. El cifrado de testigos bloquea datos detrás de una afirmación matemática. En este contexto, una clave privada de Bitcoin se cifra de forma que solo puede descifrarse si alguien presenta un testigo válido: una prueba de que la afirmación es cierta. El texto cifrado se publica fuera de la cadena, y la clave que contiene permanece inaccesible para quien no pueda producir el testigo correspondiente.
9. El mecanismo traslada la programabilidad del consenso a la criptografía. En lugar de requerir nuevos opcodes o soft forks para imponer condiciones de gasto complejas, la lógica reside íntegramente en el esquema de cifrado. Quien presente un testigo válido, como una prueba SNARK, recupera la clave privada y gasta las monedas con una firma Schnorr ordinaria. Para las reglas de consenso de Bitcoin, se trata de una transacción estándar más; la complejidad es invisible.
10. Este enfoque puede emular restricciones de tipo covenant, como CheckTemplateVerify o los vaults, sin alterar el protocolo. Las condiciones se imponen porque es imposible descifrar la clave a menos que el testigo cumpla criterios específicos. Ofrece una vía hacia condiciones de gasto avanzadas que siguen siendo compatibles con las reglas de validación existentes de Bitcoin, siempre que la criptografía subyacente resista.
11. El obstáculo principal es la escala. El artículo de febrero de 2026 estimó que cada texto cifrado tenía unos 338 terabytes; trabajos posteriores de los autores indican alrededor de 10 terabytes, lo cual sigue siendo impracticable para almacenar y distribuir. No existe ninguna implementación, por lo que se trata de estimaciones, y si los PIPEs pueden desplegarse en absoluto sigue siendo una cuestión de investigación abierta.
12. Esto sigue en fase de investigación; no es una función implementada. No hay fechas de despliegue, y las cifras contradictorias de tamaño ponen de relieve la incertidumbre del campo. Hasta que los textos cifrados se reduzcan lo suficiente, el cifrado de testigos funciona como un puente teórico entre el registro transparente de Bitcoin y compromisos criptográficos complejos, más que como una herramienta funcional para los usuarios.

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, BIP-119: OP_CHECKTEMPLATEVERIFY (2020)
• E. Heilman & A. Sabouri, BIP-347: OP_CAT in Tapscript (2024)
• S. Garg, C. Gentry, A. Sahai & B. Waters, 'Witness Encryption and its Applications' (STOC 2013)
• bitcoin-dev mailing list archives
• Abdalla, Carmer, El Gebali, Kilinc Alper, Komarov et al., 'Bitcoin PIPEs v2' (IACR ePrint 2026/186, February 2026)
• Shikhelman, Komarov & Moskvin, 'Shielded Bitcoin' ([alloc] init, September 2026)
• S. Garg et al., 'Witness Encryption and its Applications' (2013)