¿Por qué la transacción se firma con un script de bloqueo de la transacción de entrada?

Finalmente, realicé con éxito una transacción sin procesar con Python y esto es lo último, que es totalmente místico para mí.

En mi caso, aquí está la transacción de entrada y su secuencia de comandos de bloqueo es:

OP_DUP OP_HASH160 dab3cccc50d7ff2d1d2926ec85ca186e61aef105 OP_EQUALVERIFY OP_CHECKSIG

¿Por qué es necesario configurar el script de desbloqueo en el script de bloqueo de la entrada antes de firmar? Según tengo entendido, todo debería funcionar bien incluso con un script de bloqueo en blanco, porque de hecho estamos firmando solo otros parámetros. Unlocking scripty unlocking script lenghtse cambiará de todos modos, entonces, ¿cuál es la razón?

Respuestas (1)

No hay una respuesta definitiva aquí, y deberá preguntarle al creador del sistema para estar seguro.

Supongo que se debió a la interacción con una función que ahora llamamos 'delegación': la capacidad de que alguien firme previamente una transacción y agregue un nuevo script de desbloqueo, delegando efectivamente el derecho de firmar a otra persona bajo ciertas circunstancias. .

Los elementos del lenguaje de secuencias de comandos que apuntan en esta dirección incluyen la existencia de OP_CODESEPARATOR y el modelo de ejecución original de ejecutar scriptSig + scriptPubKey de una sola vez, en lugar de por separado, como se hace ahora.

Pero, ¿qué pasa con la seguridad? ¿Tengo razón? Antes de que la transacción se incluya en el bloque, el minero puede editar el script de desbloqueo + la longitud del script de desbloqueo, y la transacción seguirá siendo válida.
Sí, eso se llama maleabilidad, y es posible. Sin embargo, no se puede evitar, ya que no podemos tener firmas que se firmen a sí mismas (como lo son en el script de desbloqueo). Una forma de evitarlo es la propuesta de Segregated Witness, que no evita la maleabilidad, pero hace que el script de desbloqueo no contribuya al cálculo de txid.