比特幣錢包隔離認證開發指南

本文件的大部份內容能夠在與隔離認證相關的BIP中找到，包括BIP141，BIP143，BIP144和BIP145。請將此視爲閱讀其餘相關文件的第一個參考點，並做爲那些應該作和那些不該該作的檢查清單。

基本的隔離認證支持

錢包必須實現本節中的全部功能，以便在基本級別被視爲segwit兼容：

發送到P2SH

• 兼容segwit的錢包必須支持pay-to-script-hash（BIP16）及其地址格式（BIP13）。
• 對於付款，錢包必須可以正確地將給定的P2SH地址轉換爲scriptPubKey，並建立一個交易。
• 爲了接收付款，錢包必須可以基於P2WPKH腳本（在下文中定義）建立P2SH地址，而且可以識別對這些地址的支付。
• 這是強制性要求，即便錢包僅接受單簽名付款。

建立P2SH-P2WPKH地址

• P2SH-P2WPKH地址與比特幣的原始單簽名P2PKH地址（前綴爲1的地址）至關。
• 與任何其餘P2SH地址同樣，P2SH-P2WPKH地址的前綴爲3。
• 在使用P2SH-P2WPKH UTXO並暴露redeemScript以前，P2SH-P2WPKH地址與非segwit P2SH地址沒法區分（例如非segwit多簽名地址）。
• 當只有1個公鑰用於接收付款時（如P2PKH），應使用P2SH-P2WPKH地址。
• P2SH-P2WPKH使用與P2PKH相同的公鑰格式，但有一個很是重要的例外：P2SH-P2WPKH中使用的公鑰必須被壓縮，即大小爲33字節，並以0x02或0x03開頭。使用任何其餘格式（如未壓縮的公鑰）可能會致使不可撤銷的資金損失。
• 建立P2SH-P2WPKH地址：
• 1.計算公鑰（keyhash）的SHA256的RIPEMD160。儘管keyhash公式與P2PKH相同，但應避免重用keyhash以得到更好的隱私並防止意外使用未壓縮密鑰。
• 2.P2SH redeemScript始終爲22個字節。它以OP_0開頭，而後是keyhash的規範推送（如0x0014{20-byte keyhash}）。
• 3.與其餘P2SH相同，scriptPubKey是OP_HASH160 hash160（redeemScript）OP_EQUAL，地址是對應的P2SH地址，前綴爲3。

交易序列化

• 兼容segwit的錢包必須支持原始的交易格式，如nVersion|txins|txouts|nLockTime。
• 兼容segwit的錢包也必須支持新的序列化格式，如nVersion|marker|flag|txins|txouts|witness|nLockTime。
• nVersion，txins，txouts和nLockTime的格式與原始格式相同。
• marker必須是0x00。
• flag必須是0x01。
• witness是交易的全部見證數據的序列化。
• 每一個txin都與見證字段相關聯。做爲結果，沒有表示顯示證據字段的數量，由於它是由txins的數量默認的。
• 每一個見證字段以compactSize integer開始，以指示相應txin的堆棧項目數。而後是相應txin的見證堆棧項目數（若是有的話）。
• 每一個見證堆棧項都以compactSize integer開頭，以指示該項的字節數。
• 若是txin未與任何見證數據相關聯，則其對應的見證字段精確爲0x00，表示見證堆棧項的數量爲零。
• 若是交易中的全部txins都沒有與任何見證數據相關聯，則交易必須以原始交易格式序列化，不包括marker, flag, witness。例如，若是沒有txins來自segwit UTXO，它必須以原始交易格式序列化。（coinbase交易例外）
• 能夠在BIP143的示例部分找到交易序列化的示例。錢包開發人員可使用這些示例來測試他們的實現是否正確解析了新的序列化格式。

交易ID

• 在segwit下，每一個交易將有2個ID。
• txid的定義保持不變：原始序列化格式的double SHA256。
• 定義了一個新的wtxid，它是具備見證數據的新序列化格式的double SHA256。
• 若是交易沒有任何見證數據，則其wtxid與txid相同。
• txid仍然是交易的主要標識符：
• 當引用先前的輸出時，它必須在txin中使用。
• 若是錢包或服務當前正在使用txid來識別交易，則預示着它將繼續使用segwit。

P2SH-P2WPKH的簽名生成和驗證

• 對於非segwit UTXO的消費，簽名生成算法不變。
• 對於P2SH-P2WPKH的消費： -scriptSig必須只包含一個redeemScript。
• 相應的見證字段必須包含2個項目，簽名後跟公鑰。
• BIP143（見文末）中描述了一種用於segwit腳本的新簽名生成算法。開發人員應仔細遵循說明，並使用BIP143中的P2SH-P2WPKH示例，以確保它們可以重現sighash。
• BIP143簽名生成算法涵蓋了所花費的輸入值，簡化了air-gapped輕量錢包和硬件錢包的設計。
• 請注意，對於P2SH-P2WPKH，scriptCode老是26個字節，包括前導大小字節，如0x1976a914{20-byte keyhash}88ac，不是redeemScript，也不是scriptPubKey。
• 示例。

網絡服務（可選）

• 若是錢包經過對等網絡發送和接收交易，則須要網絡服務。
• 支持Segwit的節點將表示他們能夠經過服務位提供見證：NODE_WITNESS=(1<<3)。
• 沒有任何見證數據的交易（所以以原始格式序列化）能夠發送到有或沒有NODE_WITNESS支持的節點。
• 花費segwit UTXO（所以以新格式序列化）的交易必須僅發送到具備NODE_WITNESS支持的節點。
• 花費segwit UTXO但剝離見證數據（所以以原始格式序列化）的交易能夠發送到沒有NODE_WITNESS支持的節點。可是，這些交易在激活segwit後無效，而且在塊中不會被接受。
• 有關網絡服務的詳細信息，請參閱BIP144（見文末）。

用戶隱私

• 在segwit交易很廣泛以前，這種交易類型可使比特幣跟蹤更容易。
• 使用P2SH-P2WPKH做爲默認變化時的輸出也可能會對隱私產生影響。

交易費用估算

• 替代交易大小，定義了一個新的度量，稱爲「virtual size」（vsize）。
• 交易的vsize等於原始序列化大小的3倍，加上新格式序列化的大小，將結果除以4並向上舍入到下一個整數。例如，若是一個交易是200字節的新格式序列化，而且變爲99字節，刪除了marker,flag,witness，則vsize爲(99*3+200)/4=125並向上舍入。
• 非segwit交易的vsize只是它自己的大小。
• 交易費應經過比較vsize與其餘交易而不是大小來估算。
• 開發人員應注意不要在費用估算中犯off-by-4-times錯誤。

激活

• 從塊高度481824開始，全部SegWit就緒節點都開始執行新的SegWit共識規則。

向後兼容性

• 應繼續支持發送和接收傳統的P2PKH支付（前綴爲1的地址）。

複雜的腳本支持

若是錢包支持除單一簽名以外的腳本類型，例如多重簽名，則必須知足如下基本要求：

####　建立P2SH-P2WSH地址

• P2SH-P2WSH地址與比特幣的原始P2SH地址至關，後者容許表示具備固定大小地址的任意複雜腳本。
• 與任何其餘P2SH和P2SH-P2WPKH地址同樣，P2SH-P2WSH地址具備前綴3.在UTXO用完以前，它們沒法區分。
• 要建立P2SH-P2WSH地址：
• 1.定義一個名爲witnessScript的腳本。
• 2.計算witnessScript（scripthash）的SHA256。請注意使用單個SHA256，而不是雙SHA256和RIPEMD160（SHA256）。
• 3.P2SH redeemScript老是34個字節。它以OP_0開頭，而後是scripthash的規範推送（即0x0020{32-byte scripthash}）。
• 4.與任何其餘P2SH相同，scriptPubKey是OP_HASH160 hash160(redeemScript) OP_EQUAL，地址是對應的P2SH地址，前綴爲3。

對腳本的限制

• 腳本評測不能失敗，而且必須在評測後留下一個且只有一個TRUE堆棧項。不然，評估失敗。
• P2SH-P2WSH腳本中的任何公鑰必須是壓縮密鑰，不然資金可能永久丟失。
• 若是使用OP_IF或OP_NOTIF，則其參數必須是空向量（對於false）或0x01（對於true）。使用其餘值可能致使永久性資金損失。（BIP草案）。
• 若是OP_CHECKSIG或OP_CHECKMULTISIG返回失敗，則全部簽名必須爲空向量。不然，資金可能會永久丟失。（BIP146）。
• witnessScript的默認策略限制爲3600字節。除了witnessScript，最多能夠有100個見證堆棧項，每一個最多80個字節。超出這些限制的交易不得轉發或包含在一個區塊中。
• 許多原始腳本的共識限制，例如10000字節腳本大小，201 nOpCount，仍然適用於P2SH-P2WSH。
• P2SH的520字節腳本大小限制不適用於P2SH-P2WSH。它被3600字節的策略限制和10000字節的共識限制所取代。

P2SH-P2WSH的簽名生成和驗證

• 對於P2SH-P2WSH的消費：
• scriptSig必須只包含一個redeemScript。
• 相應見證字段的最後一個見證項必須是witnessScript。
• 新的BIP143簽名生成算法適用於：
• 在不使用任何OP_CODESEPARATOR的狀況下，scriptCode是witnessScript，前面是一個compactSize integer，用於witnessScript的大小。例如，若是腳本是OP_1（0x51），則序列化的scriptCode是（0x0151）。
• 對於包含OP_CODESEPARATOR的任何異常腳本，請參閱BIP143以獲取確切的語義。
• 在witnessScript以前的任何見證堆棧項目都用做腳本評測的輸入堆棧。輸入堆棧不會被解釋爲腳本。例如，不須要使用0x4c(OP_PUSHDATA1)來「push」大項。
• 要驗證簽名生成和堆棧序列化的正確性，請始終根據BIP143中的示例進行測試。
• 示例。

Segwit本機地址（可選）

初始segwit支持不須要如下功能。

本地Pay-to-Witness-Public-Key-Hash（P2WPKH）

• Native P2WPKH是一個22字節的scriptPubKey。它以OP_0開頭，而後是keyhash的規範推送（即0x0014{20-byte keyhash}）。
• 與P2SH-P2WPKH相同，keyhash是壓縮公鑰的RIPEMD160（SHA256）。
• 當使用原生P2WPKH時，scriptSig必須爲空，見證堆棧格式和簽名生成規則與P2SH-P2WPKH相同（包括使用壓縮公鑰的要求）。
• 示例。

本地Pay-to-Witness-Script-Hash（P2WSH）

• 原生P2WSH是一個34字節的scriptPubKey。它以OP_0開頭，而後是scripthash的規範推送（即0x0020{32-byte scripthash}）。
• 與P2SH-P2WSH相同，scripthash是witnessScript的SHA256。
• 當使用原生P2WSH時，scriptSig必須爲空，見證堆棧格式和簽名生成規則與P2SH-P2WSH相同（包括使用壓縮公鑰的要求）。
• 示例。

爲何以及如何使用Native（Bech32）P2WPKH和P2WSH？

• BIP173爲本機P2WPKH和P2WSH地址提出校驗和base32格式（Bech32）。
• 比特幣核心v0.16.0中包含對Bech32地址的支持。
• 與P2SH版本相比，在大多數狀況下，本機版本的交易vsize較小，所以可能須要較少的費用。
• 原生P2WPKH和P2WSH能夠與原始scriptPubKey協議一塊兒使用，例如支付協議（BIP70）。可是，它可能會影響付款人和收件人的隱私（見下文）。
• 原生P2WPKH和P2WSH可用做默認更改地址，但這可能容許其餘人輕鬆識別更改（參見下文）。
• 在普遍使用原生P2WPKH和P2WSH以前，這些地址類型可能會引發用戶之間的隱私問題。

腳本和事務示例

• 不一樣見證交易類型和交易有效性檢查工具的示例
• BIP141
• BIP143
• BIP144
• BIP145
• BIP173
• 腳本測試
• 有效的交易測試
• 無效的交易測試

分享2個比特幣相關的交互式在線編程實戰教程：

• java比特幣開發教程，本課程面向初學者，內容即涵蓋比特幣的核心概念，例如區塊鏈存儲、去中心化共識機制、密鑰與腳本、交易與UTXO等，同時也詳細講解如何在Java代碼中集成比特幣支持功能，例如建立地址、管理錢包、構造裸交易等，是Java工程師不可多得的比特幣開發學習課程。
• php比特幣開發教程，本課程面向初學者，內容即涵蓋比特幣的核心概念，例如區塊鏈存儲、去中心化共識機制、密鑰與腳本、交易與UTXO等，同時也詳細講解如何在Php代碼中集成比特幣支持功能，例如建立地址、管理錢包、構造裸交易等，是Php工程師不可多得的比特幣開發學習課程。

這裏是原文比特幣錢包隔離認證開發指南