Soft fork de testigo segregado: cómo se hace la financiación Tx "ANYONECANSPEND"

Lectura del BIP:

https://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki

Veo que el scriptPubKey en una transacción que financia un canje de segwit es el mismo que un P2PKH normal pero simplemente se antepone con OP_0.

¿Es este código de operación lo que les dice a los clientes más antiguos que el Tx es "cualquiera puede gastar", lo que significa que no habrá datos de firma en el Tx de canje?

Por supuesto, los nodos actualizados sabrán buscar el scriptSig real en los datos testigo para verificar el Tx. Pero, ¿cómo engaña esto OP_0a los nodos antiguos para que ignoren el scriptSig en el Tx de redención?

Respuestas (1)

No está anteponiendo un script con OP_0. Es un envío de datos que contiene el hash del programa testigo, precedido por OP_0.

Los nodos antiguos evaluarán esto como un script que simplemente inserta dos elementos de datos en la pila (un 0 y un hash). Obviamente, todos pueden gastarlo, ya que el requisito es tener un elemento distinto de cero como último elemento en la pila.

Gracias. ¿'OP0 hash' se evalúa como verdadero automáticamente para liberar las monedas? ¿Y por qué se necesita el hash del testigo? ¿Eso no vuelve a introducir la maleabilidad en el txid?
Cualquier elemento distinto de cero que quede en la pila se interpreta como una ejecución exitosa. Y no es el hash del testigo, sino el hash del programa testigo.
Entonces, ¿por qué se necesita OP_0? ¿Y qué es el programa testigo? ¿El habitual 'dup hash equalverify checksig'?
El programa testigo es el script versionado real (el equivalente del script de redención en P2SH), que se almacena dentro del testigo. La clave pública se compromete a usar ese hash. El OP_0 anterior es el número de versión testigo. Más tarde podemos usar valores más altos para hacer cualquier cambio de secuencia de comandos de una manera suave.
Entonces, ¿el código de operación real CHECKSIG está en el testigo? ¿No es el scriptPubKey? Los ejemplos en bip141 mediawiki me confunden
¡Entonces BIP141 necesita mejoras! Transmitiré el mensaje :)
@PieterWuille Pensé que esta verificación significaba que la ejecución exitosa ocurre solo si un elemento distinto de cero está en la parte superior de la pila Y es el único elemento en la pila: github.com/bitcoin/bitcoin/blob/… Entonces, en el caso de programa testigo, la pila final sería [0, <hash>], ¿cómo los nodos antiguos interpretarían esto como ANYONECANSPEND?
@SimoneBronzini La línea de código a la que se refiere está encerrada dentro de un ` (flags & SCRIPT_VERIFY_CLEANSTACK) != 0condicional, que solo se establece para verificar la estandarización, no el consenso. Entonces, si bien los clientes antiguos no transmitirían tales transacciones, son absolutamente válidas dentro de un bloque.
Soft fork de testigo segregado: cómo se hace la financiación Tx "ANYONECANSPEND"
RespuestasAquíPolítica de privacidad1y, 0v