Usé la guía , cómo hacer un depósito en garantía desde la consola de bitcoin.
Aquí están mis transacciones en testnet: tx1 tx2
Estoy confundido acerca de ScriptPublicKey en tx1:
OP_HASH160 a7a62637430b44c922cbce4fc8bd53d11b7c4c25 OP_EQUAL
Por lo tanto, solo se calcula Hash160 del valor de la pila superior y se compara con a7a6...25. En el ScriptSig de tx2 podemos ver 4 valores, que serán empujados a la pila para su validación. Pero el script vout usa solo el valor de la pila superior:
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae
Otros 2 valores son firmas:
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01
Como podemos ver, estas firmas no están validadas por el script vout.
¿Y por qué esta funcionalidad no funciona con OP_CHECKMULTISIG?
Echa un vistazo a BIP0016 .
Este nuevo tipo de transacción se canjea con un scriptSig estándar:
...signatures... {serialized script}
Y...
{secuencia de comandos serializada} se extrae de la pila inicial y la transacción se valida nuevamente utilizando la pila extraída y la secuencia de comandos deserializado como scriptPubKey.
En este caso, {serialized script}es {m [pubkey1] [pubkey2] ... [pubkeyn] n OP_CHECKMULTISIG}para una m-of-ntransacción. Cuando Bitcoin detecta una de estas transacciones especiales, el script serializado se saca de la pila tan pronto como se valida su hash (¡estás validando el hash del script! ¡No es una clave pública real!) y luego se ejecuta con la pila restante intacta.
Su secuencia de comandos de pago se ve así:
0 /* null element because a bug pops one-too-many items */
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae
La última parte ( 5221020678...52ae) es en realidad su secuencia de comandos serializada. Si lo decodificas obtienes:
2 020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f54 02bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f00 2 OP_CHECKMULTISIG
¡Qué es una transacción 2 de 2!
Las dos primeras partes que no incluyen el elemento nulo (las que parecen 304...01) son solo las firmas proporcionadas que se validarán con las claves públicas serializadas cuando OP_CHECKMULTISIGse ejecute.