Watchtowers 瞭望塔
了解閃電網路的瞭望塔機制，這是一種第三方監控服務，幫助保護離線節點免受通道詐騙。
什麼是 Watchtower？
Watchtower（瞭望塔）是閃電網路中的第三方監控服務。當你的節點離線時， 瞭望塔會持續監控區塊鏈，如果發現對方廣播了過時的通道狀態（試圖詐騙）， 瞭望塔會立即廣播懲罰交易，保護你的資金安全。
為什麼重要： 閃電網路的安全性依賴於雙方監控區塊鏈。如果你的節點長時間離線， 惡意的通道對手可能會廣播對你不利的舊狀態。瞭望塔解決了這個「在線要求」問題。
安全威脅模型
詐騙攻擊場景
Alice 和 Bob 有一個通道，經過多次交易後 Bob 擁有 0.8 BTC。 Alice 發現 Bob 離線，廣播了一個舊狀態（當時 Alice 有 0.6 BTC）。 如果 Bob 在時間鎖到期前沒有發現並懲罰 Alice，Alice 就能偷走 0.4 BTC。
Fraud Attack Timeline:
Time T0: Alice broadcasts old commitment tx
to_local (Alice): 0.6 BTC
to_remote (Bob): 0.4 BTC <- Outdated state!
|
v
Time T0 ~ T0+CSV: Dispute period
Bob must detect and punish before CSV timelock expires
Time T0+CSV: If Bob doesn't respond
Alice can spend to_local output
Threat: If Bob offline longer than CSV time (144~2016 blocks)
Bob will lose funds Watchtower 運作原理
Watchtower Architecture:
┌─────────────────┐ ┌─────────────────┐
│ Your Node │ │ Watchtower │
│ │ │ │
│ On state update │ ──────> │ Store encrypted │
│ send hint + │ │ justice tx │
│ encrypted blob │ │ │
└─────────────────┘ └────────┬────────┘
│
│ Monitor blockchain
v
┌─────────────────┐
│ Bitcoin │
│ Blockchain │
└─────────────────┘
│
│ Fraud detected?
v
┌─────────────────┐
│ Broadcast │
│ justice tx │
└─────────────────┘ Watchtower 協議設計
1. Blob 結構
為了保護隱私，客戶端不會直接發送完整的交易資訊，而是發送加密的「blob」：
Watchtower Blob Structure:
Client generates:
txid = commitment_tx txid
hint = first 16 bytes of txid (for matching)
encryption_key = SHA256(txid)
blob = AES-GCM-256(
key: encryption_key,
plaintext: justice_tx + sweep_address
)
Sent to Watchtower:
hint (16 B) | encrypted_blob
Watchtower operation:
1. Store (hint, blob) pairs
2. Monitor each new block's transactions
3. If matching hint found:
• Use txid as key to decrypt blob
• Broadcast justice_tx 2. 隱私保護
客戶端隱私
- • Watchtower 只知道 hint，不知道完整 txid
- • 加密的 blob 在沒有 txid 時無法解密
- • 不知道通道金額或對手資訊
- • 只有詐騙發生時才能得知交易細節
Watchtower 限制
- • 無法主動偷取資金（沒有私鑰）
- • 無法解密未發生的詐騙
- • 可能收取服務費（從懲罰金額中扣除）
- • 需要可靠的在線保證
BOLT 13: Watchtower 規範
BOLT 13 是 Watchtower 協議的草案規範，定義了標準化的介面：
BOLT 13 訊息類型： wt_session_init ├── tower_pubkey: 33 bytes ├── client_pubkey: 33 bytes ├── session_id: 32 bytes └── max_updates: u16 wt_state_update ├── session_id: 32 bytes ├── seq_num: u16 ├── hint: 16 bytes ├── encrypted_blob: variable └── signature: 64 bytes wt_state_update_reply ├── session_id: 32 bytes ├── seq_num: u16 ├── code: u8 (success/error) └── signature: 64 bytes 報酬模式： - Altruistic: 免費服務 - Reward: 從懲罰交易中收取百分比
主要實現
LND Watchtower
LND 內建的 Watchtower 實現，支援 Altruistic 模式。可以同時作為 Watchtower 伺服器和客戶端。
lncli wtclient add [tower_pubkey]@[host] The Eye of Satoshi
Core Lightning 的 Watchtower 插件，由 Talaia Labs 開發。支援 BOLT 13 草案。
https://github.com/talaia-labs/rust-teos Eclair Watchtower (開發中)
ACINQ 的 Eclair 正在開發 Watchtower 支援，主要用於 Phoenix 錢包。
Anchor Outputs 的影響
Anchor Outputs 對 Watchtower 設計帶來了新的挑戰和改進：
Anchor Outputs and Watchtowers: Traditional mode problem: • Justice tx fees are pre-signed • If on-chain fees spike, justice tx may get stuck Anchor Outputs improvement: Commitment Transaction contains: • to_local (with revocation) • to_remote • anchor_local (330 sats) • anchor_remote (330 sats) Watchtower can use CPFP (Child-Pays-For-Parent) to dynamically increase justice tx fee New challenges: • Watchtower needs its own UTXOs for CPFP fees • Requires more complex fee management • May need reward mechanism to cover costs
最佳實踐
對於終端用戶
- • 使用多個 Watchtower 增加冗餘
- • 選擇信譽良好的 Watchtower 服務
- • 定期檢查 Watchtower 連線狀態
- • 考慮自己運行 Watchtower
對於 Watchtower 營運者
- • 確保高可用性（99.9%+ uptime）
- • 使用可靠的 Bitcoin 節點
- • 準備足夠的 UTXO 用於 CPFP
- • 定期備份 blob 資料庫
未來發展
VLS (Validating Lightning Signer)
結合遠程簽名和 Watchtower 功能，提供更全面的安全解決方案。
OP_CHECKTEMPLATEVERIFY
未來可能使用 CTV 來簡化 Watchtower 設計，減少需要儲存的資料量。
相關資源
下一步： 了解 PTLCs 如何改進 HTLC 的隱私和功能。