在創建新事務時對先前事務進行雙重雜湊處理不清楚
我在執行上一個事務的雙 sha256 雜湊時遇到問題，本說明中的第 3 步。
之前的交易是：
084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290我已經將我想要執行的完整交易輸入到 coinb.in中，如下所示，給了我一個完整的交易：
01000000019072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08010000001976a91460077bce1849cc2a41e2ccaa6ec575b3f5b70a9d88acffffffff0120a107000000000017a9144574085e1ef5432a6b09218f3b6ab6128f8eb2a58700000000據我了解，這里之前 tx 的 double-sha256 是：
9072c913cc91d23cc11d1ee5498818672696fe0826dc06f92ca4bd5834b54f08但是，當我執行兩次 sha256 時，我得到了完全不同的東西。
例子
上一筆交易：
084fb53458bda42cf906dc2608fe962667188849e51e1dc13cd291cc13c97290第一輪 sha256（使用 anyhash.com 以十六進製作為輸入）：
9bbbb52bff2c553f84942188c87674c5b641b266baeb7ca216bebec8cd6a95bb第二輪 sha256（也是十六進制輸入）：
e5a3d32d306ef94968e0f77e6b0b496bfe9d5cd0fe6246a4ba7fd2fddf11cdf1這個最終值與 coinb.in 的交易給出的值不匹配。我在這裡錯過了什麼嗎？我看到另一個問題以相反的順序提到了交易，這到底是什麼意思？
我已經想通了。
所以在這種情況下（如果你在 blockchain.info 之類的網站上查找之前的交易），交易 ID 已經是雙雜湊交易。新交易的輸入只是交易 ID 的反面。
所以我之前的交易開始了：
90 72 c9 13 ...並且由 coinb.in 創建的完整交易結束於：
... 13 c9 72 90
好的，根據您的上一條評論（2018 年 1 月 24 日），我看到“錯誤執行腳本，用於輸入 0 引用 tx ID 0” - 我看不出它來自，所以必須查看原始 tx 本身。您在輸入部分（outpoint 索引 1）中有地址“19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP”的先前 tx (084FB53458BDA42CF…) 和公鑰雜湊 (60077BCE18…)。所以你需要有這個地址對應的私鑰。
拆卸：
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您在問題中組裝的 tx 具有正確的先前 tx ID（正確反轉），並且 v_in outpoint index 1 也是正確的。tx_out 部分花費 0.005 個比特幣到一個 P2SH，轉換為“382FYsZ6RceiPXMZLHcyonxkVRFguBHQ5T”比特幣地址。這種結構的雙 sha256 是“191b851f02e588724076e513485a65d18611f7d8d8b03a2aa6a1da996fd0525d”，你發布了一些不同的東西……但是下面的例子是正確的。這是一個在 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雙 sha256 必須得到簽名。（您可以按照參考頁面中的範例進行操作，步驟 14 中的結果顯示相反）。
我能看到的唯一區別是在第 13 步中，您的 tx.xml 文件中缺少添加的“01000000”（SIGHASHALL 的反向 01）。順便說一句：範例部分提供了對雙 sha256 的正確響應（儘管您發現它不是必需的）。我會檢查這個：
- 您提供的簽名來自私鑰，對應這個地址：19kkqPQXG5qjiiMByncH9vwkSzyeL68iCP
- 事務可能需要範例中的步驟 13 (SIGHASH_ALL)
- 對此的雙重 sha256 雜湊應該導致 6f48882e380e945143b7a0befaf6d47326ecc2ab043100a8cc1757b53902de1c
哦，還有一個提示：為什麼不使用 testnet 或 regtest？這可以防止您損失太多費用，甚至是不值得花費的輸出 :-) 使用 regtest 時，您甚至可以發布 tx 詳細資訊和密鑰，而不必擔心失去任何值……這允許其他人重播 tx 簽名過程（用他們的工具）。