Standards Track Final
BIP-324: v2 P2P 傳輸協議
為比特幣節點間通訊提供加密和認證，增強網路隱私性。
Dhruv Mehta, Tim Ruffing, Jonas Schnelli, Pieter Wuille 2019年3月8日
BIP 編號
324
類型
Standards Track
狀態
Final
創建日期
2019-03-08
摘要
BIP-324 定義了比特幣節點之間的新版本 P2P 傳輸協議（v2）。 與原始的明文協議相比，v2 提供了機會性加密（opportunistic encryption）， 使網路流量更難被監控和干擾。
為什麼需要加密？
v1 協議的問題
原始的比特幣 P2P 協議是完全明文的。ISP、政府或其他網路觀察者可以：
- • 識別比特幣節點流量
- • 追蹤交易傳播路徑
- • 進行流量分析攻擊
- • 選擇性阻斷或延遲連接
注意： 加密並不能保證完全隱私。它只是增加了攻擊成本。 流量分析和時序攻擊仍然可能洩露一些資訊。
技術概述
加密方案
BIP-324 使用以下加密原語：
| 組件 | 算法 | 用途 |
|---|---|---|
| 密鑰交換 | secp256k1 ECDH | 建立共享密鑰 |
| 密鑰派生 | HKDF-SHA256 | 從共享密鑰派生會話密鑰 |
| 對稱加密 | ChaCha20-Poly1305 | 加密和認證消息 |
| 封包格式 | Length + AEAD | 可變長度加密封包 |
握手流程
v2 連接建立流程：
- 1. 發起者生成臨時 secp256k1 密鑰對
- 2. 發起者發送 64 字節公鑰（EllSwift 編碼）
- 3. 響應者生成自己的臨時密鑰對並回覆公鑰
- 4. 雙方使用 ECDH 計算共享密鑰
- 5. 使用 HKDF 派生加密密鑰
- 6. 後續通訊使用 ChaCha20-Poly1305 加密
EllSwift 編碼
BIP-324 使用 EllSwift 編碼傳輸公鑰。這種編碼產生看起來像隨機數據的 64 字節輸出， 使協議更難被識別。
封包格式
v2 使用新的高效封包格式：
v1 封包格式（舊）： ┌─────────────┬─────────────┬──────────┬─────────┬─────────┐ │ magic (4B) │ command(12B)│ size (4B)│ check(4B)│ payload │ └─────────────┴─────────────┴──────────┴─────────┴─────────┘ 總 overhead: 24 字節 v2 封包格式（新）： ┌───────────────┬────────────────────────────────────────┐ │ length (3B) │ encrypted(1B command + payload + 16B tag) │ └───────────────┴────────────────────────────────────────┘ 總 overhead: 4-20 字節（取決於命令長度）
安全特性
- ✓ 機會性加密：自動加密，無需配置
- ✓ 前向保密：每次連接使用臨時密鑰
- ✓ 消息認證：防止篡改
- ✓ 流量混淆：難以識別比特幣流量
- ✓ 可選認證：支援節點身份驗證
v1 vs v2 比較
| 特性 | v1 (舊) | v2 (新) |
|---|---|---|
| 加密 | 無 | ChaCha20-Poly1305 |
| 認證 | 無 | AEAD + 可選節點認證 |
| 流量識別 | 容易 | 困難 |
| 封包 overhead | 24 字節 | 4-20 字節 |
| 向後相容 | - | 自動降級到 v1 |
使用方式
在 Bitcoin Core 26.0+ 中，v2 傳輸預設啟用。可以通過以下方式控制：
# bitcoin.conf
v2transport=1 # 啟用 v2 (預設)
v2transport=0 # 禁用 v2
限制
- • 不防止中間人攻擊（除非使用可選的節點認證）
- • 流量大小和時序仍可被分析
- • 需要雙方都支援 v2 才能加密
- • 初始連接建立時有少量延遲
相關 BIP
- • BIP-151：原始的 P2P 加密提案（已被 BIP-324 取代）
- • BIP-340：Schnorr 簽章（使用相同的 secp256k1 曲線）
延伸閱讀： 查看 GitHub 上的完整 BIP-324 文件
已複製連結