SIGHASH_ANYPREVOUT: La propuesta BIP 118 que flexibiliza las firmas en Bitcoin y abre nuevas posibilidades para covenants
Cómo un nuevo flag de firma SIGHASH permite reutilizar firmas entre UTXOs compatibles, facilitando protocolos de capa 2 y construcciones similares a covenants en Bitcoin.
SIGHASH_ANYPREVOUT, propuesto en BIP 118, es un nuevo valor para el flag SIGHASH que elimina la necesidad de comprometer la firma con un outpoint específico. Esta innovación, que solo se aplica a gastos desde direcciones Taproot, permite reutilizar firmas entre UTXOs compatibles, abriendo nuevas posibilidades para protocolos de capa 2 y aplicaciones similares a covenants en Bitcoin. Sin embargo, introduce riesgos de reproducción de firmas que requieren un diseño cuidadoso.
1. ¿Qué es SIGHASH_ANYPREVOUT?
SIGHASH_ANYPREVOUT no es un opcode, sino un nuevo valor para el flag SIGHASH definido en el Bitcoin Improvement Proposal (BIP) 118. Está diseñado como una actualización soft-fork para Bitcoin, lo que significa que los nodos que no lo implementen seguirán siendo compatibles con la red.
El concepto original apareció en 2015, mencionado en el whitepaper de Lightning Network por Joseph Poon y Thaddeus Dryja. Posteriormente, Joseph Poon lo propuso formalmente en febrero de 2016 como una evolución de la idea conocida como SIGHASH_NOINPUT. Desde entonces, la propuesta ha sido refinada por la comunidad técnica en la lista de correo bitcoin-dev.
Una característica técnica fundamental es que SIGHASH_ANYPREVOUT solo se aplica a gastos desde direcciones Taproot. Esta restricción existe por razones técnicas relacionadas con la implementación de la actualización, ya que Taproot introdujo cambios en el formato de las transacciones que facilitan la integración de este nuevo flag.
Para comprender su importancia, es necesario explicar primero qué es SIGHASH y cómo funciona en Bitcoin.
2. Modos SIGHASH existentes y sus limitaciones
SIGHASH es un campo en la firma de Bitcoin que determina qué partes de una transacción firma el remitente. Bitcoin cuenta actualmente con cuatro modos principales de SIGHASH, cada uno con diferentes niveles de restricción.
2.1. SIGHASH_ALL
Este es el modo más restrictivo y seguro. Firma todos los inputs, todos los outputs y el outpoint específico (la combinación de transacción e índice que identifica un UTXO). Cualquier modificación en la transacción invalida la firma.
2.2. SIGHASH_NONE
Este modo solo firma los inputs, dejando los outputs sin restricciones. Esto permite que otra persona pueda agregar o modificar los destinos de los fondos después de la firma.
2.3. SIGHASH_SINGLE
Firma todos los inputs pero solo el output que se encuentra en el mismo índice que el input firmado. Los outputs en otros índices quedan sin restricciones.
2.4. ANYONECANPAY
ANYONECANPAY no es un modo independiente, sino un modificador que se puede combinar con los modos anteriores. Permite firmar un input de manera independiente, sin comprometerse con los demás inputs de la transacción.
El punto crucial es que ninguno de estos modos permite omitir el compromiso con el outpoint. Esa es exactamente la restricción que SIGHASH_ANYPREVOUT elimina.
3. Las dos variantes de ANYPREVOUT
SIGHASH_ANYPREVOUT se presenta en dos variantes principales, cada una con diferentes niveles de flexibilidad y compromiso.
3.1. SIGHASH_ANYPREVOUT
Esta variante excluye el outpoint del digest de la firma, pero conserva el compromiso con el monto y el scriptPubKey del output anterior que se está gastando. También mantiene el compromiso con el campo nSequence del input.
Esto significa que la firma no está vinculada a un UTXO específico, pero sí lo está al valor monetario y al script de bloqueo del output gastado.
3.2. SIGHASH_ANYPREVOUTANYSCRIPT
Esta variante va un paso más allá: excluye el outpoint, el monto y el scriptPubKey. En otras palabras, la firma no está vinculada ni al UTXO específico ni al script de bloqueo del output gastado.
Es importante destacar que la selección del flag SIGHASH es decisión del firmante, no está forzada por el scriptPubKey. Esto significa que el usuario decide qué nivel de flexibilidad aplicar en cada firma.
4. La propiedad de reenlace (rebinding)
La propiedad de reenlace es la característica más innovadora de SIGHASH_ANYPREVOUT. Permite que la misma firma autorice gastar cualquier UTXO compatible, no solo aquel para el que fue creada originalmente.
Un ejemplo práctico ilustra este concepto: si se crea una transacción pre-firmada con el flag SIGHASH_ANYPREVOUT | ALL para producir un output de 0,5 BTC, esa misma firma puede reutilizarse si la misma dirección recibe otro UTXO de 0,5 BTC. En ese caso, la firma original autorizaría gastar el nuevo UTXO sin necesidad de una nueva firma.
Esta propiedad es especialmente beneficiosa para protocolos de capa 2. Una transacción pre-firmada puede aplicarse a múltiples UTXOs on-chain sin necesidad de nuevas firmas, simplificando operaciones como actualizaciones de canales de pago.
Sin embargo, existe una advertencia importante: si el nuevo UTXO contiene más de 0,5 BTC, el exceso se perderá a menos que la firma original incluyera un output de cambio. Esto requiere un diseño cuidadoso del protocolo para evitar pérdidas de fondos.
5. Aplicaciones para covenants
Dentro del ecosistema de Bitcoin, los covenants son mecanismos que restringen cómo se pueden gastar los fondos en el futuro. SIGHASH_ANYPREVOUT tiene implicaciones relevantes para este campo.
Las variantes ANYPREVOUT preservan el compromiso con el scriptPubKey del output anterior, lo que las hace más adecuadas para aplicaciones similares a covenants. Al mantener este vínculo, permiten reutilizar firmas mientras los fondos permanecen vinculados al mismo script de bloqueo.
Por el contrario, ANYPREVOUTANYSCRIPT elimina este vínculo con el script de bloqueo, lo que lo hace menos adecuado para construcciones de covenants. En esta variante, la firma puede gastar cualquier UTXO compatible, independientemente de su script de bloqueo.
En comparación con OP_CTV (CheckTemplateVerify), otra propuesta de covenant, SIGHASH_ANYPREVOUT es similar en el sentido de que mejora la lógica de transacciones pre-firmadas. Sin embargo, no permite covenants recursivos ni introspección de transacciones por sí solo. Su principal contribución es relajar el vínculo entre la firma y el UTXO específico, lo que abre nuevas posibilidades de diseño.
6. Construcciones de clave recuperada (recovered-key)
Una propiedad matemática interesante de SIGHASH_ANYPREVOUT es que eliminar el compromiso con el outpoint permite construcciones de clave recuperada. Según un análisis de Jacob Swambo y otros investigadores en 2020, titulado «Bitcoin Covenants: Three Ways to Control the Future», esta propiedad tiene aplicaciones importantes.
En estas construcciones, se puede derivar una clave pública a partir de una firma y un mensaje fijos. La clave privada correspondiente es demostrablemente desconocida para cualquiera, lo que hace que la ruta de clave del UTXO sea demostrablemente no gastable.
Esto obliga a cualquier gasto a realizarse a través de la ruta de script, eliminando la necesidad de claves temporales en construcciones que requieren únicamente la ruta de script. Es importante señalar que se trata de una construcción teórica, no de un diseño propuesto en BIP-118.
7. Riesgo principal: reproducción de firmas (signature replay)
El principal riesgo de seguridad asociado con SIGHASH_ANYPREVOUT es la reproducción de firmas, también conocida como signature replay.
Dado que las firmas ANYPREVOUT no se comprometen con un outpoint específico, la misma firma puede gastar un UTXO diferente al originalmente previsto. Las condiciones de riesgo se agravan en configuraciones específicas:
- Con ANYPREVOUT | SINGLE, cuando los montos de salida pueden reordenarse, la firma podría autorizar una distribución diferente de los fondos.
- Con ANYPREVOUT, si existe un UTXO separado con el mismo scriptPubKey y monto, la firma podría gastarlo en lugar del UTXO original.
- Con ANYPREVOUTANYSCRIPT, si existe la misma clave pública en un script compatible, la firma podría ser reutilizada para gastar un UTXO con un script de bloqueo diferente.
- Cuando un minero puede influir en el orden de las transacciones dentro de un bloque, podría explotar esta propiedad para reordenar transacciones.
Es importante contextualizar estos riesgos: estos escenarios requieren un uso deliberadamente incorrecto o un fallo en el diseño del protocolo por parte del usuario o desarrollador. No son vulnerabilidades inherentes a la propuesta, sino riesgos que deben gestionarse mediante un diseño cuidadoso.
8. Conclusión y próximos pasos
SIGHASH_ANYPREVOUT es una herramienta importante pero limitada en el ecosistema de Bitcoin. No implementa covenants por sí solo, pero facilita ciertas construcciones que se acercan a esa funcionalidad, especialmente en combinación con otras propuestas.
Las construcciones teóricas como la clave recuperada demuestran el potencial de esta propuesta, pero su implementación práctica requiere un análisis cuidadoso de los riesgos de reproducción de firmas.
El próximo artículo de esta serie explorará opcodes de soporte como OP_CHECKSIGFROMSTACK y OP_CAT. Estos opcodes extienden la expresividad de Bitcoin script, pero requieren combinación con otros opcodes para alcanzar una funcionalidad completa de covenants. La evolución de estas propuestas continúa moldeando el futuro de la programabilidad en Bitcoin.

