在錢包裡點擊「收款」，P2WPKH 給出的是以 bc1q 開頭的標準字串；換成 Taproot，拿到的則是一串以 bc1p 開頭、長度達 62 個字元的地址。兩者都能在比特幣網路上安全收款，且都屬於原生隔離見證（Native SegWit），但底層的地址編碼、交易體積（虛擬位元組 vB）、腳本隱私與錢包相容性存在本質分歧。
常見誤區是認為「新升級的 Taproot 交易費一定更便宜」。在日常單簽轉帳中，P2TR 的手續費往往反而略高於 P2WPKH；然而一旦進入多簽、複雜合約或批次歸集場景，Taproot 的架構優勢便會徹底展現。以下從底層協議到實際應用逐項釐清兩者的實質界限。
核心身分：SegWit v0 與 SegWit v1
P2WPKH（Pay to Witness Public Key Hash）屬於 SegWit v0，隨 BIP 141 於 2017 年 8 月正式激活。鎖定腳本由見證版本與公鑰雜湊構成：OP_0 <20-byte-hash>。在花費資金時，解鎖見證（Witness）區塊必須提交完整的 ECDSA 簽名（約 71–72 位元組的 DER 編碼格式）與原始未壓縮或壓縮公鑰（33 位元組）。
P2TR（Pay to Taproot）則是 SegWit v1，由 BIP 341 與 BIP 342 定義，於 2021 年 11 月激活。鎖定腳本採用 OP_1 <32-byte-x-only-pubkey>。這裡的 32 位元組公鑰經過特殊調整（Tweak），既可以直接代表單一金鑰控制權，也可以代表默克爾抽象語法樹（MAST）的根雜湊承諾。
需要釐清的是，常見以數字 3 開頭的地址是傳統的 P2SH（Pay to Script Hash） 地址。它既可能是包裝後的 SegWit（如 P2SH-P2WPKH），也可能是傳統多簽腳本，並非兩者討論的原生見證範疇。
地址格式與規格全景對照
P2WPKH 依賴 BIP 173 定義的 bech32 編碼，地址固定為 42 字元；P2TR 則採用升級後的 BIP 350 bech32m 編碼，地址長達 62 字元。兩者校驗和常數不同，因此切勿使用傳統 bech32 函式庫產生或驗證 Taproot 地址，否則會直接導致驗證崩潰或交易拒收。
| 維度指標 | P2WPKH (SegWit v0) | P2TR (SegWit v1) |
|---|---|---|
| 地址前綴與長度 | bc1q（固定 42 字元） | bc1p（固定 62 字元） |
| 編碼標準 | bech32 (BIP 173) | bech32m (BIP 350) |
| 簽名演算法 | ECDSA（DER 編碼，~71-72 位元組） | Schnorr（固定 64 位元組） |
| 錢包派生路徑 (BIP) | BIP 84 (m/84’/0’/0′) | BIP 86 (m/86’/0’/0′) |
| 單一輸出序列化大小 | 31 位元組（含金額與前綴） | 43 位元組（含金額與前綴） |
| 輸入花費體積（估算） | 約 68 vB | 約 57.5 vB（Key-path 模式） |
鏈上手續費精算：輸入省、輸出貴的結構平衡
許多使用者誤以為 Taproot 必定能降低鏈上手續費，這是未將輸入與輸出端拆分計算產生的誤判。比特幣的手續費由虛擬位元組（vB，即交易權重除以 4）決定。
在解鎖花費（輸入端）時，Taproot 的 Key-path 僅需 64 位元組 Schnorr 簽名，省去了披露公鑰的體積，使輸入大小從 P2WPKH 的約 68 vB 降至約 57.5 vB，每消耗一個輸入節省約 10.5 vB。但在資金鎖定（輸出端）時，因為 32 位元組 x-only 公鑰比 20 位元組雜湊長，導致單個輸出體積由 31 位元組增長至 43 位元組，每產生一個輸出需多支付 12 位元組成本。
典型單簽交易場景（1 輸入 2 輸出）：
- P2WPKH 交易體積：約 141 vB
- P2TR Key-path 交易體積：約 154 vB
結論：單簽日常轉帳中，包含付款與找零兩個輸出，Taproot 在輸出端多出的 24 位元組吃掉了輸入端節省的 10.5 vB，導致交易總體積反而高出約 13 vB。
只有在多輸入合併（歸集）或多簽架構下，Taproot 的優勢才會徹底釋放：
- 3 輸入 2 輸出歸集：P2WPKH 體積約為 277 vB，而 P2TR Key-path 體積降為約 269–271 vB。輸入端累積節省的 31.5 vB 超越輸出端多付的成本，開始呈現淨費率節約。
- 多簽模式（以 2-of-3 為例）：傳統 P2WSH 需在見證區公開腳本原文與多組簽名，輸入花費高達約 105 vB；若換成 Taproot 結合 MuSig2 聚合技術，多方離線協同後鏈上僅表現為單一公鑰與簽名，輸入花費維持在約 57.5 vB，每個多簽輸入節省超過 45% 體積。
- Script-path 注意事項：若動用 MAST 腳本樹的備用路徑花費，必須公開包含控制塊（Control Block，基礎 33 位元組起跳）與分支原始碼，其單個輸入體積可能飆升至 120–160 vB 以上，反而顯著昂貴。
私隱與同質性分析：理想架構與鏈上特徵
Taproot 的核心密碼學革新是同質性（Homogeneity）。在 Key-path 模式下，個人單簽、MuSig2 多方門檻簽名以及閃電網路通道關閉操作，在鏈上表現為完全相同的 32 位元組公鑰和 64 位元組 Schnorr 簽名。外部監測無法從輸出腳本判斷背後的資產治理結構。
然而，鏈上現實往往因使用者習慣與生態應用產生干擾：
- Ordinals 銘文的干擾：大量利用 P2TR 腳本樹放入圖片、文字等資料，打破了地址特徵的同質性假定。分析工具能依據特定輸入體積迅速將純資產交易與銘文劃分開來。
- 找零地址洩露指紋：若錢包從 P2TR 輸入收款，找零卻導向 P2WPKH 地址，兩者的混用會直接暴露找零流向，削弱找零隱匿性。
- 地址重複使用（Address Reuse）：任何格式在重複收款時都會關聯上下文鏈路。若多次使用同一地址，公鑰曝光後的關聯分析與傳統地址毫無二致。
錢包相容性與生態支援
在各類錢包與交易所的支援層面，P2WPKH 作為 SegWit v0 已經具備全面的相容性，幾乎所有服務商皆支援識別；而 P2TR 的普及則呈現分層狀態：
- 軟體錢包：如 Bitcoin Core、Sparrow Wallet 等開源桌面錢包已完整支援 BIP 86 單簽產生、Key-path/Script-path 花費與 Descriptor 描述符匯入；部分輕量級手機錢包則僅開放了 bc1p 的發送支援，尚未提供預設 Taproot 派生接收。
- 硬體錢包：主流裝置的最新韌體多已支援 Taproot 簽名；但若涉及自定義腳本樹與 MuSig2 聚合多簽，受限於早期低階晶片架構與記憶體空間，部分入門設備難以直接進行複雜解密與驗證。
- 交易所出入金：主流合規交易所已普遍支援提幣至 bc1p 地址，但在部分小型平台或傳統 OTC 管道中，驗證系統仍可能誤判為「無效格式」；向平台充值時亦需核對是否支援識別 bc1p 充值交易。
- 助記詞與備份警示：單簽 BIP 86 錢包可完全依照 12/24 助記詞透過固定派生路徑還原；但若使用 MAST 自訂了複雜腳本樹，助記詞僅能還原私鑰，無法還原樹狀腳本。必須妥善備份對應的錢包描述符（Descriptor）或控制塊邏輯，否則資金將永遠鎖死於鏈上。
實戰場景選型建議
日常個人單簽小額交易、面對不確定技術支援的第三方付款方、頻繁進行 1 入 2 出普通轉帳以節約手續費。
高頻商戶進行 UTXO 歸集清掃、企業級機構採用 MuSig2 實施鏈上隱私多簽、需要部署時間鎖與多重備用邏輯的複雜合約、構建低成本交互的閃電網路雙向通道。
常見問題解答（FAQ）
Q1：我可以將比特幣直接從 P2WPKH 錢包發送到 P2TR 地址嗎？
可以。只要發送方的錢包或節點支援 BIP 350（bech32m）地址驗證標準，兩種類型完全互通相容。但若發送方軟體版本過舊，可能會將 bc1p 誤報為無效地址。
Q2：為什麼日常小額轉帳時，P2TR 的手續費反而比 P2WPKH 貴？
因為比特幣交易大小是輸入與輸出的總和。常見轉帳通常包含收款與找零兩個輸出。P2TR 每個輸出佔用 43 位元組，比 P2WPKH 的 31 位元組多出 12 位元組（兩個輸出共多 24 位元組）；而 P2TR 輸入端僅省下約 10.5 vB，相抵之下總體積仍多出約 13 vB。
Q3：使用 P2TR 地址是否意味著我的鏈上活動完全匿名？
否。Taproot 提供的是腳本結構的同質性（讓多簽與單簽外觀一致），並非交易金額或流向的匿名。若發生地址重複使用、跨格式找零暴露指紋或鏈下身分關聯，鏈上監測依然能完全追蹤資金行蹤。
Q4：若遺失了自訂腳本樹的描述符，只憑助記詞能找回 Taproot 資金嗎？
標準單簽 BIP 86 錢包可以完全透過助記詞還原。但如果錢包部署了複雜條件的 MAST 腳本樹，助記詞無法推演出樹狀結構與承諾值，若缺乏描述符備份，將無法向網路構建正確的花費解鎖條件。
