比特幣錢包隔離認證開發知識點有哪些

這篇文章主要介紹“比特幣錢包隔離認證開發知識點有哪些”，在日常操作中，相信很多人在比特幣錢包隔離認證開發知識點有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”比特幣錢包隔離認證開發知識點有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

基本的隔離認證支持

錢包必須實現本節中的所有功能，以便在基本級別被視為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 hash260（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 hash260(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（Bech42）P2WPKH和P2WSH？

• BIP173為本機P2WPKH和P2WSH地址提出校驗和base32格式（Bech42）。

• 比特幣核心v0.16.0中包含對Bech42地址的支持。

• 與P2SH版本相比，在大多數情況下，本機版本的交易vsize較小，因此可能需要較少的費用。

• 原生P2WPKH和P2WSH可以與原始scriptPubKey協議一起使用，例如支付協議（BIP70）。但是，它可能會影響付款人和收件人的隱私（見下文）。

• 原生P2WPKH和P2WSH可用作默認更改地址，但這可能允許其他人輕松識別更改（參見下文）。

• 在廣泛使用原生P2WPKH和P2WSH之前，這些地址類型可能會引起用戶之間的隱私問題。

腳本和事務示例

• 不同見證交易類型和交易有效性檢查工具的示例

• BIP141

• BIP143

• BIP144

• BIP145

• BIP173

• 腳本測試

• 有效的交易測試

• 無效的交易測試

到此，關于“比特幣錢包隔離認證開發知識點有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！