比特幣--交易（轉載）
阿新 • • 發佈：2019-01-02
交易讓使用者花費satoshis(聰)。每個交易都由幾個部分構成，這些部分既可以實現簡單的直接付款，也可以實現複雜的交易。本節將介紹每個部分，並演示如何一起使用它們來構建完整的事務。
為了保持簡單，本節假設幣基交易不存在。幣基交易只能由Bitcoin 礦工建立，它們是下列許多規則的例外。不要對每條規則考慮幣基例外，請讀本指南中區塊鏈一節中的幣基交易部分。
上圖顯示了比特幣交易的主要部分。每個交易至少有一個輸入和一個輸出。每個輸入花費來源於先前的輸出的satoshis。然後，每個輸出等待未花費的交易輸出UTXO，直到稍後另外一個輸入花費它。當比特幣錢包告訴你你有10000聰，實際上意味著你有10000聰在一個或多個UTXO等待被花費。
每個交易都有四位元組交易版本號作為字首，它告訴Bitcoin節點和礦工使用哪些規則進行驗證它。這樣，開發人員可以為將來的交易建立新規則，而不會使以前的交易無效。
輸出根據其在交易中的位置具有隱含的索引號 - 第一個輸出是輸出零。輸出也有多少satoshis(聰)中的一個數額，它支付給條件pubkey指令碼。任何滿足pubkey指令碼的條件的人可以花費支付的satoshis的數額。
輸入使用交易識別符號（txid）和輸出索引號碼（通常稱為“vout” 輸出向量），來識別要花費的特定輸出。它還有一個簽名指令碼，來提供滿足pubkey指令碼中的條件的資料引數。（序列號和locktime是相關的，將在後面的小節中一起討論。）
下圖幫助說明如何使用這些功能，展示了Alice用於向Bob傳送一個交易的工作流程，以及Bob稍後用於支付的工作流程。Alice和Bob都使用最常見的標準Pay-To-Public-Key-Hash（P2PKH）交易型別。P2PKH讓Alice花費satoshis到一個典型的比特幣地址，然後讓Bob稍後用簡單金鑰對使用這些satoshis。
Creating A P2PKH Public Key Hash To Receive Payment
在Alice建立第一個交易之前，Bob必須先生成一個私有/公開的金鑰對。比特幣使用secp256k1的橢圓曲線數字簽名演算法(ECDSA)；secp256k1私鑰是256位隨機資料。該資料的副本被確定地轉換為secp256k1 公鑰。因為以後可以可靠地進行轉換，所以不需要儲存公鑰。
然後公鑰（pubkey）經過密碼雜湊運算。此pubkey雜湊運算也可以在以後可靠地重複，因此也不需要儲存。雜湊運算縮短並混淆了公鑰，使人工轉錄更容易，並提供安全性，防止從公鑰重建私鑰這樣的意外問題。
Bob向Alice提供了pubkey雜湊值。Pubkey雜湊值幾乎總是被編碼為Bitcoin 地址，它們是包含地址版本號，雜湊值，來捕獲打字錯誤的checksum錯誤檢測校驗base58編碼字串。地址可以通過任何介質傳輸，包括防止與之通訊的接收者花銷的單向介質，並可以進一步編碼為另外一種格式，例如包含比特幣URI的OR碼。
一旦Alice擁有地址並將其解碼為標準雜湊值，就可以建立第一個交易。她建立了一個包含指令的標準的P2PKH交易輸出，這個指令允許任何人花費這個輸出,若他們能證明他們控制著相應於Bob雜湊過的公鑰的私鑰。這些指令稱為pubkey指令碼或scriptPubKey。
愛麗絲廣播該交易，並將其新增到區塊鏈。網路將它歸類為未花費的交易輸出UTXO，Bob的錢包軟體也將其顯示為可花費的數額。
一段時間後，Bob決定花費UTXO，他必須建立一個輸入，該輸入引用Alice建立的有交易識別符號txid的交易和有輸出索引的特定輸出。然後他必須建立一個簽名指令碼 - 滿足Alice在之前輸出pubkey腳本里列出的條件的一組資料引數。簽名指令碼也稱為scriptSigs。
Pubkey指令碼和簽名指令碼根據條件邏輯組合secp256k1公鑰和簽名，建立一個可程式設計認證機制。
Unlocking A P2PKH Output For Spending
對於P2PKH風格的輸出，Bob的簽名指令碼將包含以下兩個資料：
Bob的secp256k1簽名不僅證明Bob控制著他的私鑰，也使得他的交易的非簽名指令碼部分防止被篡改，便於Bob安全地將他們廣播到P2P網路。
Some Things Signed When Spending An Output
如上圖所示，Bob簽名的資料包括之前交易的txid，之前輸出的pubkey指令碼，Bob建立讓下一個接收者花費交易輸出的pubkey指令碼，satoshis的金額。實質上，除了儲存完整的公鑰和secp256k1簽名的任何簽名指令碼之外，整個交易都被簽名。
在Bob把他的簽名和公鑰放到簽名指令碼之後，Bob通過P2P網路將該交易廣播給Bitcoin礦工。每個節點和礦工在進一步廣播或試圖將其加入一個包含交易的新塊之前獨立地驗證交易。
指令碼語言是一種類似Forth基於堆疊的語言，故意設計為無狀態，而不是圖靈完備的。無狀態確保一旦交易被新增到塊鏈，就沒有任何條件使其永久不可用。圖靈不完備（特別是缺少迴圈或gotos）使指令碼語言靈活性更低，更可預測，大大簡化了安全模型。
為了測試交易是否有效，從Bob的簽名指令碼開始到Alice的pubkey指令碼的末尾，簽名指令碼和pubkey指令碼操作一次執行一個條目。下圖顯示了標準P2PKH公鑰指令碼的評估過程；下圖是對該過程的描述。
P2PKH Stack Evaluation
將簽名（來自Bob的簽名指令碼）新增（壓入）一個空堆疊。因為它只是資料，除了將它新增到堆疊之外什麼都不做。公鑰（也來自簽名指令碼）被壓入到簽名之上。
從Alice的pubkey指令碼，執行OP_DUP操作。OP_DUP將當前位於其頂部的資料的副本壓入堆疊，在這種情況下建立一個Bob提供的公鑰的副本。
接下來執行的操作OP_HASH160將當前位於其上的資料即Bob的公鑰的雜湊值壓入堆疊 。這建立了一個Bob的公鑰的雜湊。
然後，Alice的pubkey指令碼將Bob在第一個交易時給她的pubkey雜湊值壓入。這樣，在堆疊頂端有兩個Bob的pubkey雜湊值。
現在變得有趣，Alice的pubkey指令碼執行OP_EQUALVERIFY，OP_EQUALVERIFY相當於執行OP_EQUAL，後跟OP_VERIFY（未顯示）。
OP_EQUAL（未顯示）檢查堆疊頂部的兩個值；在這種情況下，它檢查從Bob提供的完整的公鑰生成的pubkey雜湊值是否等於當Alice建立事務#1時提供的pubkey雜湊值 。OP_EQUAL彈出（從堆疊頂部移除）要比較的兩個值，並用比較結果替換它們：0（false）或1（true）。
OP_VERIFY（未顯示）檢查堆疊頂部的這個值。如果值為false，則會立即終止評估，並且交易驗證失敗。否則，它從堆疊中彈出true值。
最後，Alice的pubkey指令碼執行OP_CHECKSIG，它檢查Bob提供的簽名與Bob提供的現在認證的公鑰是否匹配。如果簽名與公鑰匹配，並是由所有需要簽名的資料生成的，則OP_CHECKSIGtrue 壓入堆疊的頂部。
評估pubkey指令碼後，如果false不在堆疊的頂部，則交易是有效的（只要沒有其他問題）。
Creating A P2SH Redeem Script And Hash
當Bob想要花費輸出時，他提供簽名以及有完整序列化redeem指令碼。P2P網路確保完整的redeem指令碼雜湊值和Alice放在輸出的指令碼雜湊值相等； 然後如果是主pubkey指令碼的話，它處理輸出redeem指令碼， 如果redeem指令碼不返回false的話讓Bob花費輸出。
Unlocking A P2SH Output For Spending
redeem指令碼的雜湊值具有與pubkey雜湊相通的屬性 - 可以將其轉換為標準Bitcoin地址格式，只有一個小改變以區別標準的地址。這使得獲取一個P2SH樣式的地址就像獲取P2PKH樣式地址一樣簡單。該雜湊還混淆了redeem 指令碼中的任意公鑰，因此P2SH指令碼與P2PKH pubkey雜湊一樣安全。
非標準交易 - 測試失敗當不使用預設的Bitcoin Core設定時可能會被節點接受。如果它們被包含在區塊中，它們也將避免IsStandard測試並被處理。
在multisig pubkey指令碼中，稱為m-of-n, m是需要匹配公鑰的簽名的最小數量，n是提供的公鑰數量。m和n應該是操作碼 OP_1到OP_16，對應於期望的號碼。
由於必須和原始Bitcoin實現中的一個錯誤保持相容性，OP_CHECKMULTISIG比m多消耗一個值，因此簽名指令碼的secp256k1簽名列表必須以一個無用的佔位的額外值OP_0開始。
簽名指令碼的簽名順序必須根據公鑰出現在pubkey指令碼或redeem指令碼的順序對應。有關詳細資訊，請參閱OP_CHECKMULTISIG中的說明。
雖然它不是一個單獨的交易型別，但它是一個具有2-of-3的P2SH multisig：
共識規則允許null資料輸出達到提供它們所遵循的所有其他共識規則的最大允許10000位元組的pubkey指令碼的大小，其他規則例如沒有任何資料推送大於520位元組。
Bitcoin Core 0.9.x到0.10.x預設情況下，在單個數據推送中中繼和挖掘最多40個位元組的null資料交易，並且只有一個null資料輸出，它正好支付0 satoshis。
Bitcoin Core 0.11.x將此預設值增加到80個位元組，其他規則保持不變。
Bitcoin Core 0.12.0預設中繼和挖掘null資料輸出最多可以有83個位元組，可以包含任意數量的資料推送，只要不超過總位元組數限制。但是仍然只有一個null資料輸出，它仍然必須正確地支付0 satoshis。
Bitcoin Core配置選項-datacarriersize 允許您設定要傳送或挖掘的null資料輸出中的最大位元組數。
如果您建立redeem指令碼，將其進行雜湊放入P2SH輸出中的一個雜湊值，則網路只會看到這個雜湊值，因此它不管redeem指令碼在說什麼就接受輸出有效。這允許支付給非標準指令碼，並且從Bitcoin Core 0.11起，幾乎針對所有有效的redeem指令碼。有個例外是那些使用未分配的NOP操作碼的指令碼；這些操作碼被保留用於將來的軟分叉，並且只能由不遵循標準記憶體池規則的節點進行中繼或開採。
注意：標準交易旨在保護和幫助網路，而不會阻止您發生錯誤。很容易建立標準交易，把未花費的satoshis傳送給他們。
從Bitcoin Core 0.9.3，標準交易也必須符合以下條件：
要簽署的各種選項稱為簽名雜湊型別。目前有三種基本的SIGHASH型別：
基本型別可以使用SIGHASH_ANYONECANPAY（任何人都可以支付）標誌來修改，於是建立三種新的組合型別：
Locktime允許簽名者建立時間鎖定的交易，這將只會在將來生效，使簽名者有機會改變主意。
如果任何簽名者改變主意，他們可以建立一個新的非locktime的交易。新交易使用被用於locktime交易輸入的相同的一個輸出作為它的一個輸入。如果新交易在時間鎖過期之前被加入區塊鏈，那麼這個locktime交易時將失效。
當時間鎖快到期時候需要特別小心。P2P網路允許區塊時間比真實時間提前兩小時，因此一個locktime交易可以比它的時間鎖正式過期最多提前兩個小時加入區塊鏈。此外，塊不是以確定的時間間隔建立，因此任何嘗試取消有價值的交易都應在時間鎖到期前幾個小時來實施。
以前版本的Bitcoin Core提供了一個功能，防止交易簽名者使用上述方法來取消時間鎖定的交易，但禁用此功能的必要部分以防止拒絕服務攻擊。該系統的遺留是每個輸入中的四位元組序列號。該序列號旨在允許多個簽名者去更新交易；當他們更新完交易，他們統一將每個輸入的序列號設定為四位元組無符號最大值(0xffffffff)，允許這個交易被加入一個區塊，甚至當它的時間鎖還沒過期時候。
即使在今天，將所有序列號設定為0xffffffff（Bitcoin Core中的預設值）仍然可以禁用時間鎖定，因此，如果要使用locktime，至少需要一個輸入必須有序列號低於最大值。由於序列號不被網路用於任何其他目的，將任何序列號設定為零足以啟用locktime
Locktime本身是一個無符號的4位元組整數，可以通過兩種方式進行解析：
如果小於500萬，則將locktime解析為塊高度。該交易可以新增到任何具有該高度或更高的塊。
這就是所謂的高優先順序交易的概念，它們花費長期沒挪用的satoshis。
過去，這些“優先”交易往往免除正常的費用要求。在Bitcoin Core 0.12之前，每個塊的50KB將被保留用於這些高優先順序事務，但是預設情況下現在設定為0KB。在優先順序區域之後，所有交易都將按照每位元組的費用進行優先排序，同時按順序新增更高費用的交易，直到所有可用空間都被填滿。
從Bitcoin Core 0.9開始，在網路之間廣播事務有最低費用（目前為1000 satoshis）。任何僅支付最低費用的交易應該準備好等待很長時間才能在塊中有足夠的備用空間來包含它。請參閱驗證支付部分去明白為什麼這很重要。
由於每個交易都花費未消費的交易輸出UTXOs，並且一個UTXO只能被花費一次，UTXOs的全額必須被花費或作為交易費支付給礦工。很少有人有與他們想支付的數額完全相符的UTXOs，因此多數交易都包含一個找零輸出。
如果經常使用相同的公鑰，就像人們將Bitcoin 地址（雜湊後公鑰）一樣，作為靜態支付地址一樣，其他人可以輕鬆跟蹤該人的接收和消費習慣，包括他們在已知的地址中控制的satoshis數額。
它不一定是這樣的。如果每個公鑰被使用兩次，一次就可以收到付款，並且一次支付這筆款項，使用者就可以獲得大量的財務隱私。
更好的是，在接受付款時使用新的公鑰或唯一地址，建立找零輸出時混合使用後面討論的其他技術，比如CoinJoin或合併規避，使得非常難以使用區塊鏈本身來可靠地跟蹤使用者如何接收和花費他們的satoshis。
避免金鑰重用還可以提供安全性，防止可能允許從公鑰（假設）或簽名比較來重建私鑰（在下面描述的某些情況下，假設更普遍的攻擊）。
唯一（非重用）P2PKH和P2SH地址通過保持ECDSA公鑰隱藏（雜湊後的）直到傳送到那些地址的satoshis第一次被花費來保護對抗第一種型別的攻擊， 所以這種攻擊實際上是無效的，除非他們能一兩個小時內重構私鑰，這段時間內交易通過區塊鏈得到很好的保護。
唯一（非重用）的私鑰通過一個私鑰僅生成一個簽名來保護免於第二種型別的攻擊，所以攻擊者永遠得不到後續的簽名用於基於比較的攻擊。現有的基於比較的攻擊僅在當前使用熵不足的情況下才能實現，或者當所使用的熵被暴露在某些方面（例如側通道攻擊）時。
雖然這些修改是非功能的，因此它們不會改變交易使用的輸入以及它支付的輸出 - 它們會改變交易的計算到的雜湊值。由於每個交易使用雜湊作為交易識別符號（txid）連結到以前的交易，所以修改的交易將不會有其預期的建立者的txid。
對於設計為立即新增到塊鏈的大多數比特幣交易來說，這不是問題。但是，當交易被新增到塊鏈之前，事務的輸出被花費時，確實會成為一個問題。
比特幣開發人員一直致力於在標準交易型別中減少交易可擴充套件性，但是完整的修復仍然還在規劃階段。目前，新交易不應該依賴於尚未新增到塊鏈的先前交易，特別是如果大量的satoshis受到威脅。
交易可擴充套件性也會影響付款跟蹤。Bitcoin Core的RPC介面讓您可以通過txid跟蹤交易，但是如果txid因為交易被修改而改變，那麼可能會出現交易已從網路中消失。
交易跟蹤的當前最佳做法規定，交易應該由它作為輸入的交易輸出（UTXOs）進行跟蹤，因為它們不能更改而不會使交易無效。
為了保持簡單，本節假設幣基交易不存在。幣基交易只能由Bitcoin 礦工建立，它們是下列許多規則的例外。不要對每條規則考慮幣基例外，請讀本指南中區塊鏈一節中的幣基交易部分。
上圖顯示了比特幣交易的主要部分。每個交易至少有一個輸入和一個輸出。每個輸入花費來源於先前的輸出的satoshis。然後，每個輸出等待未花費的交易輸出UTXO，直到稍後另外一個輸入花費它。當比特幣錢包告訴你你有10000聰，實際上意味著你有10000聰在一個或多個UTXO等待被花費。
每個交易都有四位元組交易版本號作為字首，它告訴Bitcoin節點和礦工使用哪些規則進行驗證它。這樣，開發人員可以為將來的交易建立新規則，而不會使以前的交易無效。
輸出根據其在交易中的位置具有隱含的索引號 - 第一個輸出是輸出零。輸出也有多少satoshis(聰)中的一個數額，它支付給條件pubkey指令碼。任何滿足pubkey指令碼的條件的人可以花費支付的satoshis的數額。
輸入使用交易識別符號（txid）和輸出索引號碼（通常稱為“vout” 輸出向量），來識別要花費的特定輸出。它還有一個簽名指令碼，來提供滿足pubkey指令碼中的條件的資料引數。（序列號和locktime是相關的，將在後面的小節中一起討論。）
下圖幫助說明如何使用這些功能，展示了Alice用於向Bob傳送一個交易的工作流程，以及Bob稍後用於支付的工作流程。Alice和Bob都使用最常見的標準Pay-To-Public-Key-Hash（P2PKH）交易型別。P2PKH讓Alice花費satoshis到一個典型的比特幣地址，然後讓Bob稍後用簡單金鑰對使用這些satoshis。
Creating A P2PKH Public Key Hash To Receive Payment
在Alice建立第一個交易之前，Bob必須先生成一個私有/公開的金鑰對。比特幣使用secp256k1的橢圓曲線數字簽名演算法(ECDSA)；secp256k1私鑰是256位隨機資料。該資料的副本被確定地轉換為secp256k1 公鑰。因為以後可以可靠地進行轉換，所以不需要儲存公鑰。
然後公鑰（pubkey）經過密碼雜湊運算。此pubkey雜湊運算也可以在以後可靠地重複，因此也不需要儲存。雜湊運算縮短並混淆了公鑰，使人工轉錄更容易，並提供安全性，防止從公鑰重建私鑰這樣的意外問題。
Bob向Alice提供了pubkey雜湊值。Pubkey雜湊值幾乎總是被編碼為Bitcoin 地址，它們是包含地址版本號，雜湊值，來捕獲打字錯誤的checksum錯誤檢測校驗base58編碼字串。地址可以通過任何介質傳輸，包括防止與之通訊的接收者花銷的單向介質，並可以進一步編碼為另外一種格式，例如包含比特幣URI的OR碼。
一旦Alice擁有地址並將其解碼為標準雜湊值，就可以建立第一個交易。她建立了一個包含指令的標準的P2PKH交易輸出，這個指令允許任何人花費這個輸出,若他們能證明他們控制著相應於Bob雜湊過的公鑰的私鑰。這些指令稱為pubkey指令碼或scriptPubKey。
愛麗絲廣播該交易，並將其新增到區塊鏈。網路將它歸類為未花費的交易輸出UTXO，Bob的錢包軟體也將其顯示為可花費的數額。
一段時間後，Bob決定花費UTXO，他必須建立一個輸入，該輸入引用Alice建立的有交易識別符號txid的交易和有輸出索引的特定輸出。然後他必須建立一個簽名指令碼 - 滿足Alice在之前輸出pubkey腳本里列出的條件的一組資料引數。簽名指令碼也稱為scriptSigs。
Pubkey指令碼和簽名指令碼根據條件邏輯組合secp256k1公鑰和簽名，建立一個可程式設計認證機制。
Unlocking A P2PKH Output For Spending
對於P2PKH風格的輸出，Bob的簽名指令碼將包含以下兩個資料：
1. 他的完整（unhashed）公鑰，所以pubkey指令碼可以檢查它的雜湊值與Alice提供的pubkey雜湊值是否相同。
2. 通過ECDSA密碼公式製作的secp256k1簽名將特定交易資料（如下所述）與Bob的私鑰組合。這使得pubkey指令碼能驗證Bob擁有建立公鑰的私鑰。
Bob的secp256k1簽名不僅證明Bob控制著他的私鑰，也使得他的交易的非簽名指令碼部分防止被篡改，便於Bob安全地將他們廣播到P2P網路。
Some Things Signed When Spending An Output
如上圖所示，Bob簽名的資料包括之前交易的txid，之前輸出的pubkey指令碼，Bob建立讓下一個接收者花費交易輸出的pubkey指令碼，satoshis的金額。實質上，除了儲存完整的公鑰和secp256k1簽名的任何簽名指令碼之外，整個交易都被簽名。
在Bob把他的簽名和公鑰放到簽名指令碼之後，Bob通過P2P網路將該交易廣播給Bitcoin礦工。每個節點和礦工在進一步廣播或試圖將其加入一個包含交易的新塊之前獨立地驗證交易。
P2PKH指令碼驗證
驗證過程需要評估簽名指令碼和pubkey指令碼。在P2PKH輸出中，pubkey指令碼是：
花費者的簽名指令碼被評估並作為指令碼的開頭。在P2PKH事務中，簽名指令碼包含secp256k1簽名（sig）和完整的公鑰（pubkey），建立以下連線：
指令碼語言是一種類似Forth基於堆疊的語言，故意設計為無狀態，而不是圖靈完備的。無狀態確保一旦交易被新增到塊鏈，就沒有任何條件使其永久不可用。圖靈不完備（特別是缺少迴圈或gotos）使指令碼語言靈活性更低，更可預測，大大簡化了安全模型。
為了測試交易是否有效，從Bob的簽名指令碼開始到Alice的pubkey指令碼的末尾，簽名指令碼和pubkey指令碼操作一次執行一個條目。下圖顯示了標準P2PKH公鑰指令碼的評估過程；下圖是對該過程的描述。
P2PKH Stack Evaluation
將簽名（來自Bob的簽名指令碼）新增（壓入）一個空堆疊。因為它只是資料，除了將它新增到堆疊之外什麼都不做。公鑰（也來自簽名指令碼）被壓入到簽名之上。
從Alice的pubkey指令碼，執行OP_DUP操作。OP_DUP將當前位於其頂部的資料的副本壓入堆疊，在這種情況下建立一個Bob提供的公鑰的副本。
接下來執行的操作OP_HASH160將當前位於其上的資料即Bob的公鑰的雜湊值壓入堆疊 。這建立了一個Bob的公鑰的雜湊。
然後，Alice的pubkey指令碼將Bob在第一個交易時給她的pubkey雜湊值壓入。這樣，在堆疊頂端有兩個Bob的pubkey雜湊值。
現在變得有趣，Alice的pubkey指令碼執行OP_EQUALVERIFY，OP_EQUALVERIFY相當於執行OP_EQUAL，後跟OP_VERIFY（未顯示）。
OP_EQUAL（未顯示）檢查堆疊頂部的兩個值；在這種情況下，它檢查從Bob提供的完整的公鑰生成的pubkey雜湊值是否等於當Alice建立事務#1時提供的pubkey雜湊值 。OP_EQUAL彈出（從堆疊頂部移除）要比較的兩個值，並用比較結果替換它們：0（false）或1（true）。
OP_VERIFY（未顯示）檢查堆疊頂部的這個值。如果值為false，則會立即終止評估，並且交易驗證失敗。否則，它從堆疊中彈出true值。
最後，Alice的pubkey指令碼執行OP_CHECKSIG，它檢查Bob提供的簽名與Bob提供的現在認證的公鑰是否匹配。如果簽名與公鑰匹配，並是由所有需要簽名的資料生成的，則OP_CHECKSIGtrue 壓入堆疊的頂部。
評估pubkey指令碼後，如果false不在堆疊的頂部，則交易是有效的（只要沒有其他問題）。
P2SH指令碼
Pubkey指令碼是由對指令碼所做的不太感興趣的消費者建立的。接收者關心指令碼條件，如果他們想要，他們可以要求消費者使用特定的公鑰指令碼。不幸的是，自定義的pubkey指令碼不如短的比特幣地址方便，並且稍後討論的在BIP70支付協議普及實現之前，沒有標準的方式在程式之間相互通訊。
為了解決這些問題，在2012年建立了pay-to-script-hash（P2SH）事務，讓一個發起人建立一個包含第二個指令碼的雜湊的pubkey指令碼redeem指令碼。
基本的P2SH工作流程如下圖所示，看起來與P2PKH工作流程幾乎相同。Bob用任何他想要的指令碼建立一個兌換指令碼，將兌換指令碼雜湊，並將兌換指令碼雜湊提供給Alice。Alice建立一個包含Bob的redeem指令碼雜湊的P2SH樣式的輸出。Creating A P2SH Redeem Script And Hash
當Bob想要花費輸出時，他提供簽名以及有完整序列化redeem指令碼。P2P網路確保完整的redeem指令碼雜湊值和Alice放在輸出的指令碼雜湊值相等； 然後如果是主pubkey指令碼的話，它處理輸出redeem指令碼， 如果redeem指令碼不返回false的話讓Bob花費輸出。
Unlocking A P2SH Output For Spending
redeem指令碼的雜湊值具有與pubkey雜湊相通的屬性 - 可以將其轉換為標準Bitcoin地址格式，只有一個小改變以區別標準的地址。這使得獲取一個P2SH樣式的地址就像獲取P2PKH樣式地址一樣簡單。該雜湊還混淆了redeem 指令碼中的任意公鑰，因此P2SH指令碼與P2PKH pubkey雜湊一樣安全。
標準交易
在比特幣早期版本中發現幾個危險的錯誤之後，添加了一個測試，它只接受來自網路的交易，如果他們的pubkey指令碼和簽名指令碼匹配一小組相信為安全的模板，並且如果其餘的交易沒有違反確保良好的網路行為的另一個小規則集。這就是IsStandard()測試，通過測試的交易稱為標準交易。非標準交易 - 測試失敗當不使用預設的Bitcoin Core設定時可能會被節點接受。如果它們被包含在區塊中，它們也將避免IsStandard測試並被處理。
除了通過廣播有害的交易來攻擊Bitcoin更加困難，標準交易測試也有助於防止使用者今天建立交易，而使新增未來的新交易功能更加困難。例如，如上所述，每個交易包括版本號 - 如果使用者開始任意地改變版本號，則作為引入向後不相容特徵的工具將變得無用。
從Bitcoin Core 0.9開始，標準的pubkey指令碼型別是：支付公鑰雜湊（P2PKH）
P2PKH是用於將交易傳送到一個或多個Bitcoin 地址的最常見的pubkey指令碼形式。支付指令碼雜湊（P2SH）
P2SH用於將交易傳送到指令碼雜湊。每個標準的pubkey指令碼可以用作P2SH redeem指令碼，但實際上只有multisig pubkey指令碼有意義的是，直到更多的交易型別成為標準。Multisig
雖然現在在mutlisig交易中廣泛使用P2SH multisig指令碼，但是在UTXO被花費之前，這個基本的指令碼可用於要求多個簽名。在multisig pubkey指令碼中，稱為m-of-n, m是需要匹配公鑰的簽名的最小數量，n是提供的公鑰數量。m和n應該是操作碼 OP_1到OP_16，對應於期望的號碼。
由於必須和原始Bitcoin實現中的一個錯誤保持相容性，OP_CHECKMULTISIG比m多消耗一個值，因此簽名指令碼的secp256k1簽名列表必須以一個無用的佔位的額外值OP_0開始。
簽名指令碼的簽名順序必須根據公鑰出現在pubkey指令碼或redeem指令碼的順序對應。有關詳細資訊，請參閱OP_CHECKMULTISIG中的說明。
雖然它不是一個單獨的交易型別，但它是一個具有2-of-3的P2SH multisig：
Pubkey
Pubkey 輸出是P2PKH pubkey指令碼的簡化形式，但它們不像P2PKH那樣安全，因此一般在新的交易不使用了。Null資料
Null資料交易型別預設在Bitcoin Core 0.9.0中繼承並開採，並且後來新增任意的資料到全節點不需要在他們的UTXO資料庫中儲存的一個證實不可花費的pubkey指令碼中。因為不能自動修剪UTXO資料庫的交易，最好使用null資料交易；然而如果可能的話通常將資料儲存在交易之外更好。共識規則允許null資料輸出達到提供它們所遵循的所有其他共識規則的最大允許10000位元組的pubkey指令碼的大小，其他規則例如沒有任何資料推送大於520位元組。
Bitcoin Core 0.9.x到0.10.x預設情況下，在單個數據推送中中繼和挖掘最多40個位元組的null資料交易，並且只有一個null資料輸出，它正好支付0 satoshis。
Bitcoin Core 0.11.x將此預設值增加到80個位元組，其他規則保持不變。
Bitcoin Core 0.12.0預設中繼和挖掘null資料輸出最多可以有83個位元組，可以包含任意數量的資料推送，只要不超過總位元組數限制。但是仍然只有一個null資料輸出，它仍然必須正確地支付0 satoshis。
Bitcoin Core配置選項-datacarriersize 允許您設定要傳送或挖掘的null資料輸出中的最大位元組數。
非標準化交易
如果你使用了非標準的pubkey指令碼在一個輸出中，使用預設Bitcoin Core設定的節點和礦工不會接受，廣播或挖掘你的交易。當您嘗試將交易廣播到執行預設設定的節點時，您將收到錯誤。如果您建立redeem指令碼，將其進行雜湊放入P2SH輸出中的一個雜湊值，則網路只會看到這個雜湊值，因此它不管redeem指令碼在說什麼就接受輸出有效。這允許支付給非標準指令碼，並且從Bitcoin Core 0.11起，幾乎針對所有有效的redeem指令碼。有個例外是那些使用未分配的NOP操作碼的指令碼；這些操作碼被保留用於將來的軟分叉，並且只能由不遵循標準記憶體池規則的節點進行中繼或開採。
注意：標準交易旨在保護和幫助網路，而不會阻止您發生錯誤。很容易建立標準交易，把未花費的satoshis傳送給他們。
從Bitcoin Core 0.9.3，標準交易也必須符合以下條件：
- 交易必須完成：它的locktime必須在過去（或小於等於當前塊高），或它裡面的所有序列號都是0xffffffff。
- 交易必須小於100,000位元組。這大約是一個典型的單輸入單輸出的P2PKH交易的200倍。
- 每個交易的簽名指令碼必須小於1,650位元組。這個足夠大來允許使用壓縮公鑰的P2SH 15-of-15 multisig交易。
- 需要超過3個公共金鑰的Bare（非P2SH）multisig事務當前是非標準的。
- 交易的簽名指令碼只能將資料壓入到指令碼評估堆疊。除了僅將資料壓入到堆疊的操作碼之外，它不能壓入新的操作碼。
- 交易不能包含比輸入少1/3的satoshis的輸出。Bitcoin Core節點當前預設的中繼費一個P2PKH或P2SH輸出 546satoshis。有個例外，標準null資料輸出必須接收0 satoshis。
簽名雜湊型別
OP_CHECKSIG從每個簽名中提取一個非堆疊引數，使得簽名者可以決定交易的哪些部分需要簽名。由於簽名保護交易的這些部分不被修改，這使得簽名者有選擇地讓其他人修改其交易。要簽署的各種選項稱為簽名雜湊型別。目前有三種基本的SIGHASH型別：
- SIGHASH_ALL，預設簽名所有輸入和輸出，保護除簽名指令碼之外的所有內容不受修改。
- SIGHASH_NONE簽名所有輸入，不簽名任何輸出，執行任何人更改satoshis的取消，除非有使用其他簽名標記的簽名保護輸出。
- SIGHASH_SINGLE與輸入索引好相同的唯一的輸出被簽名，確保沒有人能修改交易的屬於你的部分，到但是執行其他簽名者修改交易的屬於他們的部分。相應的輸出必須存在，或者值“1”將被簽名，打破了安全性方案。這個輸入以及其他輸入都包含在簽名中。其他輸入的序列號不包括在簽名中，可以更新。
基本型別可以使用SIGHASH_ANYONECANPAY（任何人都可以支付）標誌來修改，於是建立三種新的組合型別：
- SIGHASH_ALL|SIGHASH_ANYONECANPAY簽名這個輸入及其所有輸出，允許任何人新增或刪除其他輸入，以便任何人能貢獻額外的satoshis，但是他們不能改名他們傳送satoshis的數量和去向。
- SIGHASH_NONE|SIGHASH_ANYONECANPAY僅簽名這個輸入，任何人新增或刪除其他輸入或輸出，以便得到這個輸入的副本的任何人想花的話就去花費它。
- SIGHASH_SINGLE|SIGHASH_ANYONECANPAY簽名一個輸入和它相應的輸出。允許任何人新增或刪除其他輸入。
因為每個輸入就要被簽名，所以一個有多個輸入的交易包含多個簽名雜湊來簽名交易的不同部分。例如使用NONE簽名的單輸入交易有能被把它新增到區塊鏈的公開修改的輸出。另一方面，如果兩輸入交易有一個輸入用NONE簽名和一個輸入用 ALL簽名，ALL簽名者可以選擇在哪花費satoshis而不需要諮詢NONE簽名者，但是沒有其他人可以修改交易。
鎖定時間和序列號
所有簽名雜湊型別都簽名的一個東西就是交易的locktime。（在Bitcoin Core原始碼中稱為nLockTime）locktime表示交易可以新增到塊鏈的最早時間。Locktime允許簽名者建立時間鎖定的交易，這將只會在將來生效，使簽名者有機會改變主意。
如果任何簽名者改變主意，他們可以建立一個新的非locktime的交易。新交易使用被用於locktime交易輸入的相同的一個輸出作為它的一個輸入。如果新交易在時間鎖過期之前被加入區塊鏈，那麼這個locktime交易時將失效。
當時間鎖快到期時候需要特別小心。P2P網路允許區塊時間比真實時間提前兩小時，因此一個locktime交易可以比它的時間鎖正式過期最多提前兩個小時加入區塊鏈。此外，塊不是以確定的時間間隔建立，因此任何嘗試取消有價值的交易都應在時間鎖到期前幾個小時來實施。
以前版本的Bitcoin Core提供了一個功能，防止交易簽名者使用上述方法來取消時間鎖定的交易，但禁用此功能的必要部分以防止拒絕服務攻擊。該系統的遺留是每個輸入中的四位元組序列號。該序列號旨在允許多個簽名者去更新交易；當他們更新完交易，他們統一將每個輸入的序列號設定為四位元組無符號最大值(0xffffffff)，允許這個交易被加入一個區塊，甚至當它的時間鎖還沒過期時候。
即使在今天，將所有序列號設定為0xffffffff（Bitcoin Core中的預設值）仍然可以禁用時間鎖定，因此，如果要使用locktime，至少需要一個輸入必須有序列號低於最大值。由於序列號不被網路用於任何其他目的，將任何序列號設定為零足以啟用locktime
Locktime本身是一個無符號的4位元組整數，可以通過兩種方式進行解析：
如果小於500萬，則將locktime解析為塊高度。該交易可以新增到任何具有該高度或更高的塊。
如果大於等於500萬，則使用Unix紀元時間格式解析locktime（從1970-01-01T00：00 UTC到目前為止已經過去的秒數，當前超過13.95億）。交易可以被新增到塊時間大於locktime的任何塊。
交易費及其變動
交易根據簽名交易的總位元組大小支付交易費。基於在挖出區塊中的當前空間需求來計算每位元組的交易費，需求增加，交易費增加。交易費是給比特幣礦工的，因此最終送達每個礦工去選擇他們接受的最小交易費。這就是所謂的高優先順序交易的概念，它們花費長期沒挪用的satoshis。
過去，這些“優先”交易往往免除正常的費用要求。在Bitcoin Core 0.12之前，每個塊的50KB將被保留用於這些高優先順序事務，但是預設情況下現在設定為0KB。在優先順序區域之後，所有交易都將按照每位元組的費用進行優先排序，同時按順序新增更高費用的交易，直到所有可用空間都被填滿。
從Bitcoin Core 0.9開始，在網路之間廣播事務有最低費用（目前為1000 satoshis）。任何僅支付最低費用的交易應該準備好等待很長時間才能在塊中有足夠的備用空間來包含它。請參閱驗證支付部分去明白為什麼這很重要。
由於每個交易都花費未消費的交易輸出UTXOs，並且一個UTXO只能被花費一次，UTXOs的全額必須被花費或作為交易費支付給礦工。很少有人有與他們想支付的數額完全相符的UTXOs，因此多數交易都包含一個找零輸出。
找零輸出是花費UXTOs中剩餘的satoshis返回到花費者的常規輸出。它們可以重複使用與UTXO中使用的相同的P2PKH pubkey雜湊或P2SH 指令碼雜湊，但是由於下一小節，強烈建議將找零輸出傳送到新的P2PKH或P2SH地址。
避免公鑰重用
在交易中，花費者和接收者各自顯示交易中使用的所有公鑰或地址。這允許任何一個人使用公開塊鏈跟蹤涉及其他人相同的公鑰或地址的過去和未來交易。如果經常使用相同的公鑰，就像人們將Bitcoin 地址（雜湊後公鑰）一樣，作為靜態支付地址一樣，其他人可以輕鬆跟蹤該人的接收和消費習慣，包括他們在已知的地址中控制的satoshis數額。
它不一定是這樣的。如果每個公鑰被使用兩次，一次就可以收到付款，並且一次支付這筆款項，使用者就可以獲得大量的財務隱私。
更好的是，在接受付款時使用新的公鑰或唯一地址，建立找零輸出時混合使用後面討論的其他技術，比如CoinJoin或合併規避，使得非常難以使用區塊鏈本身來可靠地跟蹤使用者如何接收和花費他們的satoshis。
避免金鑰重用還可以提供安全性，防止可能允許從公鑰（假設）或簽名比較來重建私鑰（在下面描述的某些情況下，假設更普遍的攻擊）。
唯一（非重用）P2PKH和P2SH地址通過保持ECDSA公鑰隱藏（雜湊後的）直到傳送到那些地址的satoshis第一次被花費來保護對抗第一種型別的攻擊， 所以這種攻擊實際上是無效的，除非他們能一兩個小時內重構私鑰，這段時間內交易通過區塊鏈得到很好的保護。
唯一（非重用）的私鑰通過一個私鑰僅生成一個簽名來保護免於第二種型別的攻擊，所以攻擊者永遠得不到後續的簽名用於基於比較的攻擊。現有的基於比較的攻擊僅在當前使用熵不足的情況下才能實現，或者當所使用的熵被暴露在某些方面（例如側通道攻擊）時。
因此，為了隱私和安全，我們鼓勵您構建應用程式，以避免公鑰重用，並在可能的情況下阻止使用者重用地址。如果您的應用程式需要提供一個固定的URI來發送付款，請參閱下面的bitcoin:URI部分。
交易可擴充套件性
Bitcoin沒有哪種型別的簽名雜湊能保護簽名指令碼，這樣給限定的拒絕服務攻擊及交易可擴充套件性留了後門。簽名指令碼包含secp256k1簽名，它不能自籤，允許攻擊者對事務進行非功能修改，而不會使其無效。例如，攻擊者可以向簽名指令碼新增一些資料，該指令碼將在前一個pubkey指令碼被處理之前被刪除。雖然這些修改是非功能的，因此它們不會改變交易使用的輸入以及它支付的輸出 - 它們會改變交易的計算到的雜湊值。由於每個交易使用雜湊作為交易識別符號（txid）連結到以前的交易，所以修改的交易將不會有其預期的建立者的txid。
對於設計為立即新增到塊鏈的大多數比特幣交易來說，這不是問題。但是，當交易被新增到塊鏈之前，事務的輸出被花費時，確實會成為一個問題。
比特幣開發人員一直致力於在標準交易型別中減少交易可擴充套件性，但是完整的修復仍然還在規劃階段。目前，新交易不應該依賴於尚未新增到塊鏈的先前交易，特別是如果大量的satoshis受到威脅。
交易可擴充套件性也會影響付款跟蹤。Bitcoin Core的RPC介面讓您可以通過txid跟蹤交易，但是如果txid因為交易被修改而改變，那麼可能會出現交易已從網路中消失。
交易跟蹤的當前最佳做法規定，交易應該由它作為輸入的交易輸出（UTXOs）進行跟蹤，因為它們不能更改而不會使交易無效。
最佳做法進一步規定，如果交易確實似乎從網路中消失，需要重新發行，則會以無效的丟失交易方式重新發行。始終工作的一種方法是確保重新發放的支付花費與輸入所使用的丟失交易的所有相同的輸出。
轉載地址：http://blog.csdn.net/gammag/article/details/79076267