Ich habe die Anleitung verwendet , wie man ein Treuhandkonto von der Bitcoin-Konsole aus erstellt.
Hier sind meine Transaktionen im Testnet: tx1 tx2
Ich bin verwirrt über ScriptPublicKey in tx1:
OP_HASH160 a7a62637430b44c922cbce4fc8bd53d11b7c4c25 OP_EQUAL
Es wird also nur Hash160 des obersten Stapelwerts berechnet und mit verglichen a7a6...25. In der ScriptSig von tx2 sehen wir 4 Werte, die zur Validierung auf den Stack geschoben werden. Das vout-Skript verwendet jedoch nur den obersten Stapelwert:
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae
Andere 2 Werte sind Signaturen:
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01
Wie wir sehen können, werden diese Signaturen nicht vom vout-Skript validiert.
Und warum funktioniert diese Funktionalität nicht mit OP_CHECKMULTISIG?
Schauen Sie sich BIP0016 an .
Dieser neue Transaktionstyp wird durch eine Standard-ScriptSig eingelöst:
...signatures... {serialized script}
Und...
{serialisiertes Skript} wird aus dem ursprünglichen Stack entfernt, und die Transaktion wird erneut validiert, indem der entfernte Stack und das deserialisierte Skript als scriptPubKey verwendet werden.
In diesem Fall {serialized script}ist {m [pubkey1] [pubkey2] ... [pubkeyn] n OP_CHECKMULTISIG}für eine m-of-nTransaktion. Wenn Bitcoin eine dieser speziellen Transaktionen erkennt, wird das serialisierte Skript aus dem Stack entfernt, sobald sein Hash validiert ist (Sie validieren den Skript-Hash! keinen tatsächlichen öffentlichen Schlüssel!) und dann mit dem verbleibenden Stack intakt ausgeführt.
Ihr Zahlungsskript sieht folgendermaßen aus:
0 /* null element because a bug pops one-too-many items */
304402205fdee0b00f5e2fa07324458fe06b47a41bb2ef4e73892343796e9f6456e378940220630b423ce14b0d5ed487da751c368d7fc0122efa21cac1a4afce7c3c017bf29f01
304502205edb6ce77a772346b21d60a775c81f52bec9e8957f795fce7ea4fab862bc656c022100fc1376399134348fae516d6e627b1f72c094affd3ba2f458685bdbe9b6a51f5e01
5221020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f542102bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f0052ae
Der letzte Teil ( 5221020678...52ae) ist eigentlich Ihr serialisiertes Skript. Wenn Sie es entschlüsseln, erhalten Sie:
2 020678adff50855b6748e93ab03667968817363fff84306d7ffc13276191fd7f54 02bff39dce7ae4c6a06104ac4e49948eb7bac9d4a82e9e16df41b1436d31b76f00 2 OP_CHECKMULTISIG
Welches ist eine 2-von-2-Transaktion!
Die ersten beiden Teile ohne das Nullelement (die wie aussehen ) sind nur Ihre bereitgestellten Signaturen, die bei der Ausführung 304...01gegen die serialisierten öffentlichen Schlüssel validiert werden .OP_CHECKMULTISIG