Signieren einer Rohtransaktion mit mehreren Eingaben

Also erstelle ich eine einfache P2PKH-Transaktion und nachdem ich darüber recherchiert hatte, fand ich hier einige nützliche Beiträge und Antworten; Ich konnte einen einzelnen P2PKH UTXO erfolgreich ausgeben, aber es wird wirklich kompliziert, wenn ich versuche, Transaktionen mit mehreren Eingaben auszugeben. Ich habe einen ganzen Tag damit verbracht.

Alle Transaktionen finden auf Bitcoin Testnet statt.

Ausgaben, die ich einlöse:

  1. Tx Hash: 9742ed783bfec215ec6484d82dae20fba582229e54c49e06d662a91ead3f6a54 Index: 0 scriptPubKey: OP_DUP OP_HASH160 81f52d4061313b6f63549efc03f3df6cb6f0149e OP_EQUALVERY

  2. Tx-Hash: 40dbd3c25073cb7222becead1eb9bb2195cf309cf5b24af559f3391168ec6318 Index: 0 scriptPubKey: OP_DUP OP_HASH160 81f52d4061313b6f63549efc03f3df6cb6f0149e OP_EQUALVERIFY

Jetzt habe ich eine Antwort von hier gelesen, die vorschlug, bei Verwendung mehrerer Eingaben scriptSig für die restlichen Eingaben (die nicht signierten) durch leer zu ersetzen. Und diese Varianten habe ich bisher ausprobiert:

1. scriptSig für Eingänge durch „00“ ersetzen

Nur die signierte Eingabe (UTXO) hat also ihren scriptPubKey, und andere Eingaben sollten "00" haben.

Serialized input #1 when signed:
01000000
02
546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
00000000
19
76a91481F52D4061313B6F63549EFC03F3DF6CB6F0149E88ac
ffffffff
1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
00000000
00
ffffffff
01
c0fb390000000000
19
76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
00000000
01000000

Und...

Serialized input #2 when signed:
01000000
02
546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
00000000
00
ffffffff
1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
00000000
19
76a914A17C43FE0E1F8E660B044C9538E2CEF4ABFDCED288ac
ffffffff
01
c0fb390000000000
19
76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
00000000
01000000

Haupttransaktion mit beiden Eingaben signiert: (Signaturen ohne 01-Hashcode-Typ-Suffix und öffentliche Schlüssel sind fett gedruckt)

01000000
02
546a3fad1ea962d6069ec4549e2282a5fb20ae2dd88464ec15c2fe3b78ed4297
00000000
6a
4730440220E4A366646391B3CFB06C0C4B0343E678B560BE8A2D20418233DEE863986105E502207245C5BA3DB516E59B95764C1716F5B39850E20429F08B91389C4780CE45430E 0121 025F69830D2BA35D04CA9EFB3EA46AA2645BBBDCB592A189A539480657C9696137
ffffffff
1863ec681139f359f54ab2f59c30cf9521bbb91eadcebe2272cb7350c2d3db40
00000000
6a
4730440220C41C498D0CA55E38FE85DD158FDE82BB451068124E2B3AA2391D861BA9281EDD0220165712ADF71B19DF525583D8F48B82DFF06B2E556C17A583F4D5C54E99412C6B 0121 039F9AF4A84A8D5C35DD7A5628F8C2DC1894C2B4BDD4815DAFFDCBC9102FE2BA26
ffffffff
01
c0fb390000000000
19
76a914DD02C23FF4C3FFC6DA1C74B7EA5BCB0891B0E98288ac
00000000

Jetzt funktioniert die Dekodierung der Rohtransaktion, aber beim Versuch, sie zu übertragen, gibt Bitcoind diese Fehler aus:

Mandatory-Script-Verify-Flag-failed (Signatur muss null sein für fehlgeschlagene CHECK(MULTI)SIG-Operation) (Code 16)

oder

non-mandatory-script-verify-flag (nicht kanonische DER-Signatur) (Code 64)

Ich habe verschiedene Varianten ausprobiert:

  1. Ersetzen Sie scriptPubKey von Eingaben, die nicht mit "00" signiert werden.
  2. Ersetzen Sie scriptPubKey von Eingaben, die nicht mit "" signiert werden.
  3. Folgenummer aus Eingängen entfernen "ffffff"

aber nichts scheint zu funktionieren. Was mache ich falsch? Ihre Hilfe wird geschätzt :)

Antworten (1)

und andere Eingänge sollten "00" haben.

Denken Sie daran, dass Sie "scriptsig" durch "leer" ersetzen und die 0x00Größe des leeren Skripts ist.

non-mandatory-script-verify-flag (nicht kanonische DER-Signatur) (Code 64)

Das Problem hier ist die in Ihren Signaturen verwendete DER-Codierung. rWerte in einer Signatur sind positiv und da jeder rWert, den Sie haben, sein höchstwertiges Bit gesetzt hat, benötigen sie ein vorangestelltes Zeichen, 0x00um dem DER-Decoder mitzuteilen, dass die Zahlen positiv sind:

0xE4 = 0b11100100 
0xC4 = 0b11000100 

Jede Signatur sollte sich wie folgt ändern:483045022100E4A3...

Du hast Recht!!! Ich war verrückt nach der Transaktionsvorbereitung, während das Problem von der Seite der ECDSA-Bibliothek kam. Danke, Mann!