Entiendo que los tipos de transacciones P2SH se agregaron "suavemente" al reutilizar un mensaje Tx que ya es válido, por lo que los nodos antiguos no los rechazarán en bloques.
¿Existe un método similar para agregar nuevos códigos OP de script sin una bifurcación dura? En otras palabras, ¿cómo interpretarán los nodos antiguos los comandos "No Op" después de haber sido reutilizados para el protocolo actualizado?
Sí. Antes de P2SH, la propuesta más popular para resolver el problema que resuelve P2SH era OP_EVAL, que hizo exactamente eso: reutilizó OP_NOP1 como OP_EVAL.
Una secuencia de comandos P2SH se ve así:
[script input...] [serialized script] | OP_HASH160 [script hash] OP_EQUAL
La secuencia de comandos OP_EVAL equivalente se vería así en los nodos antiguos: los nodos
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_NOP1
antiguos solo verificarían que la secuencia de comandos serializada coincida con el hash de secuencia de comandos dado cuando se aplica el hash. Las otras cosas serían ignoradas.
Los nuevos nodos verían:
[script input] [serialized script] | OP_DUP OP_HASH160 [script hash] OP_EQUALVERIFY OP_EVAL
Los nuevos nodos entenderían OP_EVAL, por lo que verificarían que el script serializado coincida con el script dado y ejecutarán el script serializado. Una transacción OP_EVAL puede verse como no válida para nodos nuevos y válida para nodos antiguos, pero no al revés. Eso es lo que lo convierte en un softfork. Si la mayoría de la potencia minera está usando las nuevas reglas, entonces esto no es una bifurcación dura porque la cadena más larga siempre convergerá a un estado que sea válido tanto para los nodos antiguos como para los nuevos.
Dependiendo del comportamiento del nuevo código de operación, puede ser necesario que los nuevos nodos verifiquen los scripts dos veces para asegurarse de que ciertos scripts no puedan causar hardforks. Los scripts se verifican una vez con las reglas de script antiguas y una vez con las reglas nuevas.
La propuesta OP_EVAL finalmente se reemplazó con P2SH porque se descubrió que OP_EVAL accidentalmente permitió scripts completos de Turing, que los desarrolladores de Bitcoin no querían. P2SH es muy simple (y un poco extraño) en parte para que accidentes similares sean fáciles de evitar. Pero no hubo ningún problema técnico con este método de agregar un nuevo código de operación. Además, no hay nada que restrinja el comportamiento de los nuevos códigos de operación. Por ejemplo, OP_EVAL podría haber interpretado su entrada en un lenguaje completo de Turing diferente, aunque hay varias razones por las que esto podría no haber sido una buena idea.
La introducción de P2SH no significó nuevos códigos OP ni la reutilización de los antiguos.
No puede cambiar ningún código OP existente con una bifurcación suave por definición. Lo único que puede hacer es interpretar la información para nuevas aplicaciones. Por ejemplo, puede incluir el hash de un documento para crear un esquema de prueba de existencia.
The introduction P2SH didn't mean new OP codes nor repurposing old ones.Eso es técnicamente cierto (no reutilizamos OP_EQUAL, reutilizamos OP_HASH160 <data> OP_EQUAL) pero es terriblemente engañoso.op_hash160 <20 bytes> op_equalretuvo su significado original para los nodos no actualizados, pero los nodos actualizados solo permitían gastar una P2SH scriptPubKey si el scriptSig de gasto contenía un script redimido que no devolvía falso.
cabeza de alfiler
ellos
OP_TRUE, pero cualquier constante distinta de cero funcionará. No tiene mucho sentido hacerlo, pero podrías usar P2SH si quieres:OP_HASH160 [hash of OP_TRUE script] OP_EQUAL.cabeza de alfiler
OP_HASH160 [HASH OF SOMETHING] OP_EQUALcomo un script de salida si noSOMETHINGes un script válido (podría ser cualquier dato) como en.bitcoin.it/wiki/Script#Transaction_puzzleellos
OP_0 OP_HASH160 [HASH OF SOMETHING] OP_EQUAL.ellos