Th testnet TxID 8d897ca91774a7fafa086a3275e679248d6bffee015d3b2efefd5dab00df152d hat den folgenden scriptPubKey :
scriptPubKey: "OP_DUP OP_HASH160 5f1426c2ce4a8e1abaa9dbe819b6303eb8a25a26 OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_IF OP_DUP OP_HASH160 6c7ceafe76c56843c9d2868f616fdc9370355eb9 OP_EQUALVERIFY OP_CHECKSIG OP_ELSE OP_HASH256 644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e OP_EQUAL OP_ENDIF"
Wenn wir uns das Skript des einlösenden Tx ( TxID: 2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105 ) ansehen, sehen wir:
7e 10 3ceb50edd0282cd99dc59351f513dcdf 00 der sig
Ich kann das also im Wesentlichen sehen, weil sha256(sha256(3ceb50edd0282cd99dc59351f513dcdf))= 644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8edas Skript als wahr validiert wird.
Ich versuche zu verstehen, wie das funktioniert, erhalte aber für diesen Versuch ständig einen Fehlercode 26 (OP_EQUALVERIFY-Fehler) sendrawtransaction:
01000000013261e80001cbcc53101036792dcc8edc6802940b81a06e6e38f34765a4a5e4e5000000008b483045022100fe3890cfe091789b8300e563bbad402421a8dc07096ba04bcaaa4dd3537e7ce302204a1d7d1d33b6101599385f74164d95fdd8c00f62062a339e6d4907334b17df5f0141042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9ffffffff0220402c00000000001976a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac20402c00000000005876a914e900510876cb689f1db6fa982376c301362b740c88ad6376a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac67aa20644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e876800000000
Wo genau tritt dieses Problem auf?
Auch im Allgemeinen , wenn man Daten vor der Signatur auf den Stapel schieben muss , wie wird das gemacht? Werden die Daten, die dem scriptSig-Feld hinzugefügt und dann signiert wurden, oder signiert und dann der scriptSig hinzugefügt? (Ich habe Probleme, den Stack zu visualisieren, selbst mit diesem interaktiven Szenario bei webbtc )
Die erste einlösende Transaktion hat eine scriptSig in der Form:
<value to be double hashed> 0 <signature> <public key>
Das 7eist ein Ablenkungsmanöver - es ist die Größe des scriptSig. Ebenso 10ist die Größe der zu hashenden Daten.
Die zweite Transaktion scheint zu versuchen, eine Standardausgabe auszugeben . Es scheint zu versuchen, dies mit einem Schlüssel auszugeben, der nicht den richtigen Wert hat.
Sie können dies sehen, indem Sie das folgende Skript in die Bitcoin Script IDE einfügen :
042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9 OP_DUP OP_HASH160 e900510876cb689f1db6fa982376c301362b740c OP_EQUALVERIFY OP_CHECKSIG
Zauberer von Ozzie
Zauberer von Ozzie
Nick Odell