本文件的大部分內容可以在與隔離認證相關的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。
- 1.計算公鑰（
交易序列化
- 兼容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，表示見證堆棧項的數量爲零。
- 每個txin都與見證字段相關聯。作爲結果，沒有表示顯示證據字段的數量，因爲它是由
-
- 如果交易中的所有
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。
- 1.定義一個名爲
對腳本的限制
- 腳本評測不能失敗，並且必須在評測後留下一個且只有一個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之前，這些地址類型可能會引起用戶之間的隱私問題。
腳本和事務示例
安利2個比特幣相關的交互式在線編程實戰教程：
java比特幣開發教程，本課程面向初學者，內容即涵蓋比特幣的核心概念，例如區塊鏈存儲、去中心化共識機制、密鑰與腳本、交易與UTXO等，同時也詳細講解如何在Java代碼中集成比特幣支持功能，例如創建地址、管理錢包、構造裸交易等，是Java工程師不可多得的比特幣開發學習課程。
php比特幣開發教程，本課程面向初學者，內容即涵蓋比特幣的核心概念，例如區塊鏈存儲、去中心化共識機制、密鑰與腳本、交易與UTXO等，同時也詳細講解如何在Php代碼中集成比特幣支持功能，例如創建地址、管理錢包、構造裸交易等，是Php工程師不可多得的比特幣開發學習課程。
這裏是原文比特幣隔離認證錢包開發指南