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

區塊鏈開發 · 發表 2018-11-01 21:20:43

摘要：本檔案的大部分內容可以在與隔離認證相關的BIP中找到，包括BIP141，BIP143，BIP144和BIP145。請將此視為閱讀其他相關檔案的第一個參考點，並作為那些應該做和那些不應該做的檢查清單。基本的隔離認證支援錢包必須實現本節中的所有功能，以便在基本級別被視為segwit...

本檔案的大部分內容可以在與隔離認證相關的BIP中找到，包括BIP141，BIP143，BIP144和BIP145。請將此視為閱讀其他相關檔案的第一個參考點，並作為那些應該做和那些不應該做的檢查清單。

基本的隔離認證支援

錢包必須實現本節中的所有功能，以便在基本級別被視為segwit相容：

傳送到P2SH

相容segwit的錢包必須支援pay-to-script-hash （ofollow,noindex">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.P2SHredeemScript 始終為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
```

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 。
- 示例。

網路服務（可選）

NODE_WITNESS=(1<<3)
NODE_WITNESS
NODE_WITNESS

使用者隱私

在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.P2SHredeemScript 總是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位元組指令碼大小，201nOpCount ，仍然適用於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？

vsize
scriptPubKey

指令碼和事務示例

======================================================================

分享一些以太坊、EOS、比特幣等區塊鏈相關的互動式線上程式設計實戰教程：

java以太坊開發教程，主要是針對java和android程式員進行區塊鏈以太坊開發的web3j詳解。
python以太坊，主要是針對python工程師使用web3.py進行區塊鏈以太坊開發的詳解。
php以太坊，主要是介紹使用php進行智慧合約開發互動，進行賬號建立、交易、轉賬、代幣開發以及過濾器和交易等內容。
以太坊入門教程，主要介紹智慧合約與dapp應用開發，適合入門。
以太坊開發進階教程，主要是介紹使用node.js、mongodb、區塊鏈、ipfs實現去中心化電商DApp實戰，適合進階。
C#以太坊，主要講解如何使用C#開發基於.Net的以太坊應用，包括賬戶管理、狀態與交易、智慧合約開發與互動、過濾器和交易等。
EOS教程，本課程幫助你快速入門EOS區塊鏈去中心化應用的開發，內容涵蓋EOS工具鏈、賬戶與錢包、發行代幣、智慧合約開發與部署、使用程式碼與智慧合約互動等核心知識點，最後綜合運用各知識點完成一個便籤DApp的開發。
java比特幣開發教程，本課程面向初學者，內容即涵蓋比特幣的核心概念，例如區塊鏈儲存、去中心化共識機制、金鑰與指令碼、交易與UTXO等，同時也詳細講解如何在Java程式碼中整合比特幣支援功能，例如建立地址、管理錢包、構造裸交易等，是Java工程師不可多得的比特幣開發學習課程。
php比特幣開發教程，本課程面向初學者，內容即涵蓋比特幣的核心概念，例如區塊鏈儲存、去中心化共識機制、金鑰與指令碼、交易與UTXO等，同時也詳細講解如何在Php程式碼中整合比特幣支援功能，例如建立地址、管理錢包、構造裸交易等，是Php工程師不可多得的比特幣開發學習課程。

匯智網原創翻譯，轉載請標明出處。這裡是原文