Abrufen der Transaktions-ID aus der Rohtransaktion einer Multisig-Adresse

Ich kann die tx-ID (oder den Transaktions-Hash) von fast jeder Transaktion abrufen, außer der, bei der das Skript mit einem "OP_O" beginnt (was meiner Meinung nach der hier eingeführte Null-Dummy ist https://github.com/bitcoin /bitcoin/pull/3843 )

Zum Beispiel:

https://www.blockchain.com/btc/tx/97d1b00fcef1f19531a19bb1722635341a9f2ad261ecf6eed89eca2cbd3bb3ee

Wie soll ich die txid dieser Transaktion erhalten? Und wie unterscheidet es sich von einem normalen (ohne Multisig)?

Antworten (1)

Wie soll ich die txid dieser Transaktion erhalten?

Auf die gleiche Weise erhalten Sie die txid jeder anderen Transaktion, indem Sie sie hashen (es sei denn, es handelt sich um Segwit). Beachten Sie, dass die Transaktion, mit der Sie verknüpft sind, keine Segwit-Transaktion ist, sodass Sie einfach ihren Hash nehmen können.

Wenn es sich bei der Transaktion um eine Segwit-Transaktion handelt (wie durch die Markierungs- und Flag-Bytes nach 0x0001den Versionsbytes angegeben), müssen Sie nur die Teile hashen, die nicht Segwit sind. Insbesondere lassen Sie alle Segwit-Teile fallen (also den Marker und die Flagge und alle Zeugen, die zwischen der letzten Ausgabe und der Sperrzeit gefunden werden können) und hashen, was übrig bleibt. Dies ist im BIP 144 beschrieben .

Und wie unterscheidet es sich von einem normalen (ohne Multisig)?

Gibt es nicht.

Danke, ich werde meinen Code noch einmal überprüfen. Ich habe es an einem vollen Block (ca. 2.000 txs) getestet und das einzige Mal, dass die txid nicht übereinstimmte (20 Mal), war, als ein "OP_0" in einem der Eingabeskripts erschien.
Außerdem hash ich die Transaktion nicht einfach so, wie sie ist. Ich parse es, speichere alle seine Elemente in einer Datenstruktur und hänge sie dann wieder an und hash sie (ich verwende die tx-ID als Fehlerprüfung).
OP_0 wird auch in Segwit-Transaktionen verwendet, das könnte also Ihr Problem sein.
Problem gelöst: Ich hatte ein Problem mit meiner "varint"-Funktion... Danke!
FWIW, bekam 2022 das gleiche Symptom, aber von einem anderen zugrunde liegenden Problem. OP_PUSHDATA1 konnte seinen Opcode 0x4c in der Transaktion nicht codieren. Offensichtlich trat das gleiche Problem bei OP_PUSHDATA2 und OP_PUSHDATA4 auf.