解釋decoderawtransaction輸出欄位和解釋
我試圖在廣播之前以十六進制獲取有關原始交易的資訊。此命令採用 JSON 格式的多個元素。我想為他們做一個更簡單的解釋：
txid - 交易本身的雜湊
hash - 交易本身的雜湊值。如果交易是非隔離見證，則 txid == 雜湊，否則在隔離見證交易中，交易雜湊是不同的。
版本- 這是顯而易見的，但應該如何解釋？
size - 交易的大小（以字節為單位）
vsize - 隔離見證交易的加權大小
locktime - 此事務的鎖定時間，無論是在塊高度還是在 unix 時間。OP_CLTV 只能從redeemscript 中確定，而不是從該欄位中確定。
vin - 這個子集包括所有花費的輸入。
- txid - 正在使用的輸入的 txid。
- vout - 這是什麼？
- scriptSig - asm / hex - 這包括此特定輸入的簽名和redeemScript。asm 和 hex 有什麼區別嗎？
- 序列- 如何解釋？如何確定輸入是否被 CSV 鎖定，或者是否可以通過費用 (RBF) 替換？
vout - 這個子集包括交易的所有輸出：
- value - 此輸出的數量。
- n - 這看起來像輸出的數量/順序？
- scriptPubKey - 輸出的腳本或 pubkeyhash
- reqSigs - 發件人如何僅通過地址提前知道這一點？
- 類型- 這怎麼能提前知道呢？
附加問題：
- 如何確定vin子集中每個輸入的數量？
- 如何驗證 scriptSig，例如：輸入 CLTV 或 CSV 是否被鎖定？贖回腳本（如果是 p2sh）是否驗證為真（例如，所需的可用 sig 數量，滿足其他 IF/ELSE 規則）？
您的文章有點長，在堆棧交換中，我們更喜歡 shotrt，易於回答問題 - 請參見此處：https ://bitcoin.stackexchange.com/help/how-to-ask
您可能有一個 JSON 解釋範例作為參考。你從哪裡得到它？由於每個人都可以解釋原始交易，我認為最好參考來自 bitcoin.org的原始原始交易。這是模棱兩可的。它看起來像這樣（非隔離見證，以保持輕鬆。隔離見證僅在需要時 :-)
VERSION TX_IN COUNT (how many input this tx has) TX_IN[0...n] OutPoint hash (the previous tx where funds come from) OutPoint index (the n'th TX_IN) Script Length (the length of the following Script Sig) Script Sig (signature) Sequence (a sequence field, originally intended to disable lock-time) TX_OUT COUNT (how many outputs this tx has) TX_OUT[0...n] Value (the value in Satoshis) PK_Script Length (length of the following script) pk_script (the script, which defines the condition, under which the funds can be spent) LOCKTIME (earliest time or earliest block when that transaction may be added to the block chain)@amaclin here的回答很好地解釋了發送前的 tx 組裝。
如何確定 vin 子集中每個輸入的數量？
當想要花費一筆新交易時，錢包軟體需要查找這些值。因此需要對先前的 tx 的引用，其中找到 v_in。如果目前花費的金額不足，則將使用另一個 v_in 甚至另一個帶有 v_in 的 tx（TX_IN 計數將增加）。
如何驗證 scriptSig，例如：輸入 CLTV 或 CSV 是否被鎖定？
我不明白你的意思。Scriptsig 和 CLTV/CSV 沒有直接連結到 scriptsig。CLTV 和 CSV 都通過 BIP-68 和 BIP-112 進入遊戲。CLTV（也是鎖定時間）都是絕對時間鎖，而 CSV 我們談論相對時間鎖。因此，他們定義了何時可以使用交易的輸出。也許值得在 BIP 中查找。這裡的論壇和 bitcointalk 中也有很多內容。
Scriptsig（通常）使用散列和公鑰進行驗證。Ken Shirrif 的部落格（連結在底部）解釋得很好。Scriptsig 證明，您擁有花費這筆交易的私鑰（“您是合法所有者”）。privkey 對 tx 的雜湊進行簽名，然後是 pubkey。它可以有更多，但我想保持一般。這是一個範例，您可以如何使用 openssl 在 unixoide 系統 shell 上驗證簽名（比特幣總是使用十六進制編碼的數據進行雜湊處理，而 openssl 需要 PEM 格式的密鑰）：
sig=30450221009a29101094b283ae62a6fed68603c554ca3a624b9a78d83e8065edcf97ae231b02202cbed6e796ee6f4caf30edef8f5597a08a6be265d6601ad92283990b55c038fa pk=03F5D0FB955F95DD6BE6115CE85661DB412EC6A08ABCBFCE7DA0BA8297C6CC0EC4 hash=4eb4dccd727e81315a9ff801c205efc62635471cf8668e42c1c8aebfb51500a3 printf $( echo $hash | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_utx_dsha256.hex echo "MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=" > cat pubkey.pem printf $( echo $sig | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sig.hex openssl pkeyutl <tmp_utx_dsha256.hex -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex贖回腳本（如果是 p2sh）是否驗證為真（例如，所需的可用 sig 數量，滿足其他 IF/ELSE 規則）？
贖回腳本基本上是“某物”的散列。當資金交易被探勘到區塊鏈中時，它具有“隱藏”預期的優勢。當您創建支出交易時，您的 p2sh 腳本的數據就會顯示出來。常見的用法是多重簽名腳本。但是您可以將所有類型的程式碼放入其中，這將定義可以使用資金的條件（在多重簽名旁邊，任何類型的智能合約，……）。它有局限性。此處解釋了可以使用的操作碼。在 bitcoin.org 中也有關於 p2sh 的解釋。
我從另外兩篇參考資料中學到了這一切：Andreas 寫的令人難以置信的好書“Mastering Bitcoin” ，以及Ken Shirrif對交易的非常好的解釋。
txid - 交易本身的雜湊
確實。它是不包括見證數據（如果有）的交易雜湊。
hash - 交易本身的雜湊值。如果交易是非隔離見證，則 txid == 雜湊，否則在隔離見證交易中，交易雜湊是不同的。
確實。它是包含見證數據（如果有）的交易的雜湊值。計算的序列化在BIP144中定義。
版本- 這是顯而易見的，但應該如何解釋？
它報告事務
nVersion欄位的內容。目前定義了兩個事務版本號：
- 1：原始版本號
- 2：在BIP68中定義。具有此版本號（或更高版本）的事務的
nSequence欄位根據 BIP68 中指定的新規則進行解釋。- 任何其他版本號都是非標準的（不會被網路上的普通節點軟體中繼），但被阻止有效性規則允許。0 與 1 含義相同；3 及以上與 2 具有相同的含義。
size - 交易的大小（以字節為單位）
確實。它是事務序列化的大小。
vsize - 隔離見證交易的加權大小
確實。它是序列化的大小，其中見證數據按因子 4 折現，如BIP141中所指定。
locktime - 此事務的鎖定時間，無論是在塊高度還是在 unix 時間。OP_CLTV 只能從redeemscript 中確定，而不是從該欄位中確定。
確實。它報告交易
nLocktime欄位的值。這是交易不能包含在區塊中的時間或高度。因此，例如，locktime700000 的交易只能包含在高度為 700001 或更高的塊中。
OP_CHECKLOCKTIMEVERIFY操作碼（又名OP_CLTV；在BIP65中定義）提供了一種從腳本內部強制執行nLocktime支出交易欄位的約束的方法，從而間接限制可以花費輸出的時間。它適用於所有腳本結構（裸、P2SH、P2WSH，…），但在裸腳本中是非標準的。vin - 這個子集包括所有花費的輸入。
這是一個數組，包含有關所有交易輸入的資訊，這些資訊儲存在其
vin欄位中。
- txid - 正在使用的輸入的 txid。
更具體地說，它是
hash交易輸入prevout欄位的值，其中包含創建該輸入所花費的 UTXO 的交易的 txid。
- vout - 這是什麼？
它是
n交易輸入prevout欄位的值。它報告正在使用創建事務vout數組中的哪個索引。
- scriptSig - asm / hex - 這包括此特定輸入的簽名和redeemScript。asm 和 hex 有什麼區別嗎？
確實。十六進制值正是儲存在事務中的值。asm 值是對該數據的更易讀的解碼。
- 序列- 如何解釋？如何確定輸入是否被 CSV 鎖定，或者是否可以通過費用 (RBF) 替換？
它是交易
nSequence欄位的值。它的現代意義是雙重的：
- 每當交易具有
nVersion2 或更高，並且nSequence值小於2 2時，就會應用BIP68規則，該規則限制了在該交易有效之前花費的輸出必須在多長時間之前（高度或時間）。BIP112操作碼OP_CHECKSEQUENCEVERIFY（又名OP_CSV）在腳本中提供了一種對nSequence值施加約束的方法（從而間接地限制了輸出可以花費的相對時間）。- BIP125為節點在記憶體池中替換交易指定了一個潛在的策略（不是共識規則）。具體來說，它允許替換任何
nSequence值不是 0xFFFFFFF 或 0xFFFFFFFE 的事務。如上面的要點中所討論的，任何使用相對鎖定時間的事務輸入都是這種情況。請注意，在撰寫本文時，現代節點並未完全實現 BIP125 策略規則，儘管不會以使該描述無效的方式。vout - 這個子集包括交易的所有輸出：
這是一個數組，包含有關所有交易輸出的資訊，這些資訊儲存在其
vout欄位中。
- value - 此輸出的數量。
確實。
- n - 這看起來像輸出的數量/順序？
它類似於輸入中的vout場。當輸入花費此輸出創建的特定 UTXO 時，它需要引用此交易的 txid 和
n欄位。
- scriptPubKey - 輸出的腳本或 pubkeyhash
它包含正在創建的 UTXO 的鎖定腳本，它定義了可以使用它的條件。對於 P2PKH 輸出，這是一個腳本，需要由其雜湊是特定值的公鑰簽名，但它仍然是一個腳本。
- reqSigs - 發件人如何僅通過地址提前知道這一點？
它可以，但僅適用於裸 multisig 腳本（完整腳本直接儲存在輸出中，而不是通過redeemScript），這些腳本已被棄用且非標準寫作。由於這個原因，reqSigs 欄位現在也被棄用了。這只是令人困惑。
- 類型- 這怎麼能提前知道呢？
它是輸出的類型。例如，它可以區分 P2PKH 或 P2SH 輸出。它無法知道 P2SH 輸出的腳本是什麼，直到它被用完。
- 如何確定 vin 子集中每個輸入的數量？
花費時間在 UTXO 集數據庫中查找它，使用 RPC 輸出中報告的
txid和vout欄位。這兩個唯一標識一個交易輸出（vouttxid 為 的交易的數量txid），UTXO 集記住它的amount和scriptPubKey欄位。
- 如何驗證 scriptSig，例如：輸入 CLTV 或 CSV 是否被鎖定？贖回腳本（如果是 p2sh）是否驗證為真（例如，所需的可用 sig 數量，滿足其他 IF/ELSE 規則）？
執行過程大致如下：
- 首先
scriptSig執行。最終的堆棧狀態被記住。如果失敗，則交易無效。- 然後
scriptPubKey執行正在花費的輸出，以之前的最終堆棧狀態作為初始狀態。這scriptPubKey是在上面列出的 UTXO 數據庫中查找的。所以這有效地做的是執行鎖定腳本，scriptSig作為輸入；如果失敗，則交易無效。- 然後，作為一個特殊步驟，如果
scriptPubKey與BIP16 (P2SH) 模板完全匹配，則會觸發附加規則：最終的 scriptSig 元素被視為另一個腳本，並使用除最終 scriptSig 元素之外的所有元素作為輸入來執行。類似的規則適用於 P2WSH (BIP141) 和 P2TR (BIP341) 支出。