Saltar al contenido
buybitcoinsmart

Glosario / Protocolo y actualizaciones

SIGHASH_ANYPREVOUT

También se conoce como APO.

¿Qué es SIGHASH_ANYPREVOUT?
SIGHASH_ANYPREVOUT es un modo de firma propuesto para scripts de Taproot que permite que una sola firma gaste cualquier moneda bloqueada en un script coincidente, en lugar de la única moneda para la que se hizo.

Se especifica en el BIP-118.

BIP-118 define un nuevo tipo de clave pública para tapscript, de 33 bytes y que empieza por 0x01, en lugar de un indicador añadido a las claves ordinarias. Asignado en febrero de 2017, nunca se ha activado, y solo funciona en gastos por ruta de script, nunca en gastos por ruta de clave. Nada de su billetera puede firmar de este modo, así que cualquier producto que prometa canales eltoo en la mainnet está describiendo un futuro.

Cómo funciona

Estado: BIP-118 es un Draft (borrador), asignado con fecha 2017-02-28, que requiere BIP-340, BIP-341 y BIP-342, y su propia sección Deployment (despliegue) dice TODO. No se reemplazó nada, porque nada entró en vigor.

Una firma Taproot cubre el outpoint de la moneda que se gasta, 36 bytes de txid e índice en el hash de ANYONECANPAY que BIP-118 modifica, y eso la suelda a una sola moneda para siempre. Si se elimina el outpoint del mensaje que se firma, la firma deja de nombrar una moneda y empieza a nombrar una forma, de modo que más tarde se le puede asociar cualquier UTXO de esa forma. El BIP lo llama dynamic rebinding (reasociación dinámica).

Se definen dos variantes, y la diferencia entre ellas es lo que la firma sigue cubriendo.

  • SIGHASH_ANYPREVOUT, con valor de bit 0x40, omite el outpoint, pero conserva el monto de la entrada (8 bytes), su scriptPubKey (aquí siempre de 35 bytes) y el hash de hoja. La firma encaja entonces con cualquier moneda que tenga el mismo valor bajo el mismo script.
  • SIGHASH_ANYPREVOUTANYSCRIPT, con valor de bit 0xc0, omite además el monto, el scriptPubKey y el hash de hoja. Encaja con cualquier moneda cuyo script esa clave pueda satisfacer.

Se opta por esta capacidad al crear la dirección, no en el momento de firmar. Estas claves solo funcionan a través de una hoja de tapscript, así que la dirección tiene que llevar una hoja así en su árbol de Merkle, y hasta que se gasta es indistinguible de cualquier otra dirección Taproot. Una sola constante sella la separación entre ambas: key_version vale 0x01 para una clave BIP-118 frente a 0x00 para una clave de tapscript corriente, de modo que una misma clave privada no puede producir una firma que sea válida con las dos reglas. Seis bytes hash_type nuevos pasan a ser válidos: 0x41, 0x42, 0x43, 0xc1, 0xc2 y 0xc3.

Dónde aparece

SIGHASH_ANYPREVOUT no aparece en ninguna transacción de la mainnet, y BIP-118 prevé que, incluso cuando exista, "only be rarely used in practice" (solo se usará rara vez en la práctica), ya que los gastos por ruta de script pesan más y son más fáciles de identificar.

El diseño para el que se escribió es eltoo, un esquema de actualización off-chain. Los protocolos off-chain tienen que responder a cualquier estado antiguo que publique una contraparte, y como una firma ordinaria cubre la transacción exacta a la que responde, hace falta una firma nueva para cada estado que pueda aparecer. Eltoo, en cambio, usa el script y el campo nLockTime para hacer asimétricas las firmas, de modo que una transacción con una firma posterior puede gastar otra con una firma anterior, pero nunca al revés, y una sola firma de actualización puede aplicarse sobre cualquier actualización anterior que haya publicado su contraparte.

El nombre deja constancia de una corrección. Joseph Poon propuso la idea como SIGHASH_NOINPUT en febrero de 2016, después de que la planteara el artículo original de Lightning, y el cambio de nombre indica que la entrada no se ignora realmente: el campo nSequence siempre se firma, y con SIGHASH_ANYPREVOUT también se firman el script y el monto.

La sección de seguridad del BIP nombra el precio: la repetición. Una firma ANYPREVOUT puede reutilizarse contra cualquier otro UTXO con el mismo script y el mismo valor, y una firma ANYPREVOUTANYSCRIPT, contra cualquier UTXO que reutilice esa clave en uno de sus scripts, así que la reutilización de claves pasa de ser una molestia para la privacidad a una forma de perder dinero. Estas transacciones también son maleables por desconocidos: cualquiera capaz de aportar una entrada coincidente puede cambiar el txid sin ninguna clave privada.

SIGHASH_ANYPREVOUT frente a SIGHASH_ANYONECANPAY

SIGHASH_ANYONECANPAY existe hoy en la red y elimina todas las entradas salvo la que se firma; SIGHASH_ANYPREVOUT elimina además parte de esa entrada superviviente. BIP-118 describe su hash como el hash de ANYONECANPAY sin el outpoint, una diferencia de una línea con una gran consecuencia. Una firma ANYONECANPAY no puede repetirse, porque el outpoint que nombra solo puede gastarse una vez. Si se renuncia a ese compromiso, la protección contra la repetición tiene que venir del protocolo construido encima, no de la firma.

No confundir con

Preguntas frecuentes

¿Puedo usar SIGHASH_ANYPREVOUT hoy?

No. BIP-118 sigue en estado Draft, su sección Deployment dice TODO y ningún nodo de la mainnet hace cumplir sus reglas, así que nada firmado de este modo puede gastarse en la mainnet.

¿Es SIGHASH_ANYPREVOUT lo mismo que SIGHASH_NOINPUT?

Sí, es la versión renombrada y reelaborada de la misma idea. Joseph Poon propuso SIGHASH_NOINPUT en febrero de 2016; el borrador ANYPREVOUT se limita a los gastos por ruta de script de Taproot y sus firmas siguen cubriendo nSequence y, de forma opcional, el script y el monto, que es lo que refleja el nuevo nombre.

¿Por qué BIP-118 define un nuevo tipo de clave pública en lugar de un simple indicador nuevo?

Porque hay que optar por esa capacidad al crear la dirección. Estas firmas solo funcionan con una clave pública BIP-118 dentro de una hoja de tapscript, así que una dirección sin esa hoja nunca puede gastarse de este modo, y sigue siendo indistinguible de cualquier otra dirección Taproot hasta que se gasta.

Para seguir leyendo

Términos relacionados

Más en la sección Protocolo y actualizaciones

Leer esta página en inglés