Ich habe Probleme bei der Ausführung des Double-Sha256-Hash der vorherigen Transaktion, Schritt 3 in dieser Erklärung.
Die vorherige Transaktion ist:
084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290
Ich habe die vollständige Transaktion, die ich durchführen möchte, in coinb.in eingegeben , wie hier gezeigt , und erhalte eine vollständige Transaktion von:
01000000019072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08010000001976a91460077bce1849cc2a41e2ccaa6ec575b3f5b70a9d88acffffffff0120a107000000000017a9144574085e1ef5432a6b09218f3b6ab6128f8eb2a58700000000
Soweit ich weiß, ist das Doppel-sha256 des vorherigen TX hier:
9072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08
Wenn ich jedoch zweimal sha256 durchführe, erhalte ich etwas völlig anderes.
Beispiel
Vorherige Transaktion:
084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290
Runde eins sha256 ( mit Hex als Eingabe unter Verwendung von anyhash.com ):
9bbbb52bff2c553f84942188c87674c5b641b266baeb7ca216bebec8cd6a95bb
Runde zwei sha256 (auch Hex-Eingabe):
e5a3d32d306ef94968e0f77e6b0b496bfe9d5cd0fe6246a4ba7fd2fddf11cdf1
Dieser endgültige Wert stimmt nicht mit dem Wert überein, der von der Transaktion von coinb.in angegeben wird. Übersehe ich hier etwas? Ich sehe, dass die andere Frage die Transaktion in umgekehrter Reihenfolge erwähnt , was genau bedeutet das?
Ich habe es herausgefunden.
In diesem Fall (und wenn Sie eine frühere Transaktion auf Websites wie blockchain.info nachschlagen) ist die Transaktions-ID also bereits die doppelt gehashte Transaktion. Die Eingabe für die neue Transaktion ist nur die Umkehrung der Transaktions-ID.
Meine vorherige Transaktion beginnt also:90 72 c9 13 ...
und die vollständige Transaktion, die von coinb.in erstellt wurde, endet in:... 13 c9 72 90
Error running script for input 0 referencing [transaction ID] at 0: Script was NOT verified successfully.ok, basierend auf Ihrem letzten Kommentar (24. Januar 2018) sehe ich "Fehler beim Ausführen des Skripts für Eingabe 0, auf die TX-ID 0 verweisen" - ich kann nicht sehen, woher es kommt, also muss ich den Roh-TX selbst überprüfen. Sie haben den vorherigen tx (084FB53458BDA42CF ...) und den Pubkey-Hash (60077BCE18 ...) der Adresse "19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP" im Eingabeabschnitt (Outpoint-Index 1). Sie müssen also den entsprechenden Privkey für diese Adresse haben.
Demontage:
01000000019072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08010000001976a91460077bce1849cc2a41e2ccaa6ec575b3f5b70a9d88acffffffff0120a107000000000017a9144574085e1ef5432a6b09218f3b6ab6128f8eb2a58700000000
VERSION
01000000
TX_IN COUNT [var_int]: hex=01, decimal=1
TX_IN[0]
TX_IN[0] OutPoint hash (char[32])
084FB53458BDA42CF906DC2608FE962667188849E51E1DC13CD291CC13C97290
TX_IN[0] OutPoint index (uint32_t)
hex=01000000, reversed=00000001, decimal=1
TX_IN[0] Script Length (var_int)
hex=19, decimal=25
TX_IN[0] Script Sig (uchar[])
76A91460077BCE1849CC2A41E2CCAA6EC575B3F5B70A9D88AC
TX_IN[0] Sequence (uint32_t)
FFFFFFFF
TX_OUT COUNT, hex=01, decimal=1
TX_OUT[0]
TX_OUT[0] Value (uint64_t)
hex=20A1070000000000, reversed_hex=000000000007A120, dec=500000, bitcoin=0.00500000
TX_OUT[0] PK_Script Length (var_int)
hex=17, dec=23
TX_OUT[0] pk_script (uchar[])
A9144574085E1EF5432A6B09218F3B6AB6128F8EB2A587
LOCK_TIME
00000000
Ihr zusammengesetzter TX in der Frage hat die richtige vorherige TX-ID (korrekt umgekehrt), und auch der v_in-Outpoint-Index 1 ist korrekt. Der tx_out-Teil gibt 0,005 Bitcoin an einen P2SH aus, was in die Bitcoin-Adresse „382FYsZ6RceiPXMZLHcyonxkVRFguBHQ5T“ übersetzt wird. Das doppelte sha256 dieser Struktur ist "191b851f02e588724076e513485a65d18611f7d8d8b03a2aa6a1da996fd0525d", Sie haben etwas anderes gepostet ... Die folgenden Beispiele sind jedoch korrekt. Hier ist ein kurzes Skript zum Konvertieren auf der OpenBSD / OSX / Linux-Shell:
#!/bin/sh
# Bitcoin never does hashes with the hex strings,
# so need to convert it to hex codes in file:
tmp_hex_fn=tmp_file.hex
tmp_hex_sha256_fn=tmp_sha256.hex
tmp_txt_sha256_fn=tmp_sha256.txt
tmp_hex_dsha256_fn=tmp_dsha256.hex
tmp_txt_dsha256_fn=tmp_dsha256.txt
printf $( echo $1 | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > $tmp_hex_fn
hexdump -C $tmp_hex_fn
# sha256
openssl dgst -sha256 <$tmp_hex_fn >$tmp_txt_sha256_fn
openssl dgst -sha256 -binary <$tmp_hex_fn >$tmp_hex_sha256_fn
openssl dgst -sha256 <$tmp_hex_sha256_fn >$tmp_txt_dsha256_fn
openssl dgst -sha256 -binary <$tmp_hex_sha256_fn >$tmp_hex_dsha256_fn
printf "sha256: "
cat $tmp_txt_sha256_fn
printf "dsha256: "
cat $tmp_txt_dsha256_fn
Das doppelte sha256 müsste signiert werden. (Sie können dem Beispiel von der referenzierten Seite folgen, das Ergebnis in Schritt 14 wird umgekehrt angezeigt).
Und der einzige Unterschied, den ich sehen kann, ist in Schritt 13, wo das hinzugefügte "01000000" (umgekehrte 01 für SIGHASHALL) in Ihrem tx fehlt. Übrigens: Der Beispielabschnitt liefert korrekte Antworten auf das doppelte sha256 (obwohl dies, wie Sie herausgefunden haben, nicht erforderlich ist). Ich würde das prüfen:
Die von Ihnen bereitgestellte Signatur stammt aus dem Privatschlüssel, der dieser Adresse entspricht: 19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP
Die Transaktion benötigt möglicherweise den Schritt 13 aus dem Beispiel (SIGHASH_ALL)
der doubla sha256 hash dafür sollte dann 6f48882e380e945143b7a0befaf6d47326ecc2ab043100a8cc1757b53902de1c ergeben
Ach, noch ein Hinweis: Warum benutzt du nicht testnet oder regtest? Dies verhindert, dass Sie zu viele Gebühren oder sogar wertlose Ausgaben verlieren :-) Wenn Sie Regtest verwenden, können Sie sogar TX-Details und -Schlüssel posten, ohne befürchten zu müssen, Werte zu verlieren ... Dies ermöglicht anderen, den TX-Signaturprozess nachzuspielen ( mit ihren Werkzeugen).
pebwindkraft