手機錢包能在極小儲存空間內順暢運作，關鍵在於它從不下載整條區塊鏈。客戶端僅同步每個 80 位元組的區塊頭，一年累積產生的數據量僅約 4.2 MB，運行十多年也僅佔幾十 MB，並藉由工作量證明確認具備最長累積難度的主鏈。私鑰維持在本地端保管，看似隔絕了外洩風險，但輕量區塊頭僅能證明特定區塊的存在性，無法告知特定交易是否與自身地址相關。
為了掌握餘額與交易動態，錢包必須主動向全節點發起查詢。早期的比特幣輕錢包為了在不直接交出完整公鑰的前提下取得資料，引入了基於概率的資料結構，將查詢條件壓縮後送出，這便是 Bloom 過濾器（Bloom Filter）。當這份壓縮指紋離開裝置、進入對等網路節點的記憶體與連線日誌時，使用者的交易意圖與關聯特徵就已經暴露在外部環境中。
輕錢包把驗證責任與查詢可見性一併讓渡
簡易支付驗證（SPV）最初的設計目標，是讓運算與儲存資源受限的終端能透過 Merkle 分支，核對交易是否被收錄在具備工作量證明的區塊中。然而，Merkle 證明僅能核實「該筆交易確實存在於特定區塊」，並不能保證交易輸入合法、腳本未被竄改，更無法驗證節點是否隱瞞了其他重要記錄。
這導致輕錢包在架構上做出了兩項妥協：一是放棄自主核查全局共識規則的能力，依賴遠端節點傳回證明；二是交出了查詢意圖，因為它必須告知節點自己關注的資產特徵才能獲取更新。私鑰未遺失並不代表隱私安全，鏈上地址關聯一旦在廣播或查詢過程中被外部節點還原，便會形成不可逆的永久痕跡。
BIP37 查詢機制：過濾器本身就是一份高辨識度指紋
節點收到的不只是隨機位元
根據 BIP37 規範，客戶端透過 filterload 訊息傳遞過濾器，其包含位元陣列長度、雜湊函數數量（k）、加鹽隨機數（nTweak）以及匹配標記（nFlags）。隨機數 nTweak 隨請求明文發送，目的僅是降低雜湊碰撞偏誤，並無法隱藏過濾器本身的結構特徵。監聽節點完全可以離線保存這些參數，持續進行交叉統計與模型推演。
差分比對讓新地址當場暴露
當錢包產生新地址或更新監聽腳本時，若直接發送 filteradd，傳送的即是原始公鑰或腳本數據而非雜湊值，節點能立即解碼出具體收款特徵。即使錢包選擇重新建構並發送全新的 filterload，外部節點只要比對前後兩版過濾器的位元差異，配合鏈上公開的未花費交易輸出（UTXO），即可透過差分分析快速鎖定新增的關聯地址。
nFlags 賦予節點追蹤過濾器演進的能力
BIP37 中的更新控制項（例如 BLOOM_UPDATE_ALL）允許節點在命中匹配交易時，自動將符合條件的輸出（Outputs）及相關公鑰腳本加入現有過濾器中，避免錢包頻繁手動重傳。但這項便利性使節點能夠精確追蹤過濾器的演變路徑，清楚掌握哪一筆鏈上交易直接驅動了過濾器狀態的更新。
時間、請求區間與網路層特徵交織
節點記錄的維度不僅限於加密數據。手機輕錢包通常在啟動應用程式時建立 TCP 連線並發送查詢，節點日誌記錄的連線時間、請求同步的起始區塊高度、中繼查詢頻率與來源 IP，足以描繪出高度精確的行為輪廓。若搭配交易所提幣記錄或電信業者出口特徵，地址叢集分析的成功率將大幅提升。
假陽性率在隱私保護與裝置效能間的拉鋸
Bloom 過濾器的理論假陽性率公式為 (1 − e^(−kn/m))^k，其中 m 代表位元陣列長度，n 為插入元素個數，k 是雜湊函數數量。假陽性的存在本是為了混淆節點視聽，讓節點傳回部分無關的交易干擾判斷，藉此保護真實意圖。
然而在行動端開發中，較高的假陽性率意味著必須下載更多無效交易與 Merkle 分支，直接導致網路頻寬消耗與電池耗損增加。多數錢包函式庫在實務設定中會將假陽性率設得極低（例如部分實作環境預設值落在 0.0001 左右），致使傳回的命中結果幾乎全為真實交易，原先設計的混淆掩護在現實效能考量下形同虛設。
評估輕錢包隱私安全的核心標準在於：終端裝置在何時、以何種精確度、將自身關聯的資產索引交付給了誰。
節點信任邊界與主動操縱風險
輕錢包依賴未受信任的對等節點提供數據。惡意或受監控的節點不僅能被動記錄查詢請求，還能採取主動干預策略：刻意扣留未確認交易造成未入帳假象、拒絕轉發使用者的合法簽名交易，或透過日蝕攻擊（Eclipse Attack）孤立錢包連線，向其廣播孤立鏈上的無效狀態。
分散連線至多個節點固然能降低單點故障與斷線機率，但在隱私維度上，將同一份過濾器同步廣播至多個公用節點，反而擴大了查詢數據的外洩範圍。日誌保留政策與監控實體的不透明，進一步放大了可見性風險。
架構轉移後的隱私現狀與替代方案
隨著 Bitcoin Core 於 0.19.0 版本將預設參數 -peerbloomfilters 調整為關閉，公用網路對舊式 BIP37 的原生支援顯著減少。輕錢包生態隨之發展出不同的架構路徑，其隱私權衡也隨之轉移：
- 緊湊區塊過濾器（BIP157 / BIP158）：全節點依區塊內容預先產出 Golomb 編碼過濾器，錢包客戶端整批下載至本地自主比對。裝置不再向外界透露查詢目標，但代價是需承擔額外的過濾器下載頻寬與本地索引運算開銷。
- Electrum 伺服器協議：客戶端直接將地址的腳本雜湊發送至特定伺服器獲取歷史。查詢速度快且資源負擔極低，但營運端能完整獲取該錢包的所有資產總額與動態，信任高度集中。
- 第三方 API 與後端中繼：部分商業錢包透過中心化 REST 介面查驗資產，請求常夾帶裝置識別碼、IP 與認證金鑰，隱私防護最為薄弱。
- 自建全節點與專用索引：本地架設節點（如搭配 Electrs 或 Fulcrum），由私有伺服器處理查詢，能完全杜絕外部監控，惟需投入硬體與維護成本。
不同網路架構下的隱私暴露程度比對
| 連線架構 | 外部節點／伺服器獲取的資訊 | 核心脆弱點 | 暴露風險 |
|---|---|---|---|
| 舊版 BIP37 錢包連公用節點 | 過濾器結構、filterload 變更歷程、請求 IP | 差分分析高機率還原所屬地址 | 高 |
| 公用 Electrum 伺服器連線 | 完整腳本雜湊、歷史交易記錄、網路特徵 | 單一營運方全面掌握關聯資產清單 | 中高 |
| 第三方集中式 API 服務 | 明文地址、裝置硬體指紋、請求時間序 | 日誌多方儲存，易與身分資料比對綁定 | 中高 |
| 緊湊過濾器（BIP157/158）＋ Tor | 過濾器下載行為、匿名網路出口特徵 | 潛在流量特徵關聯，仰賴過濾器標頭驗證 | 中低 |
| 自建專屬節點＋加密連線通道 | 無外部查詢暴露，僅自身節點留存紀錄 | 私有伺服器維護與本機網路配置安全性 | 低 |
降低輕錢包隱私暴露的防護指引
- 釐清錢包後端連線機制：查閱軟體網路設定與技術說明，確認同步協議是走緊湊過濾器、Electrum 協定或第三方商業 API。
- 優先指定專屬節點：若具備技術條件，建議自行搭建全節點並搭配專用索引層，設定錢包僅連線至自有節點位址。
- 正確認識網路層匿名工具：Tor 僅遮蔽實體 IP，無法阻止應用層將地址與查詢特徵送往外部伺服器。
- 貫徹地址隔離規範：不同來源與用途的資產應嚴格區分帳戶與錢包，避免因單一交易交叉簽名造成鏈上聚類關聯。使用時應確保符合所處司法管轄區之合規與申報要求。
- 關閉非必要推播服務：部分行動錢包依賴中心化伺服器推播交易通知，啟用時可能在背景將監聽地址登錄至第三方系統。
常見問題 FAQ
為什麼早期輕錢包普遍採用 Bloom 過濾器？
因為早期行動裝置儲存空間與行動網路流量有限。BIP37 設計旨在讓裝置以極低資源運作，由全節點代為篩選匹配數據，是在早期頻寬條件受限下的工程折衷產物。
如果錢包每次收款都更換新地址，能否抵禦過濾器差分分析？
無法完全抵禦。錢包將新地址加入過濾器時所產生的增量位元變化，在靜態比對環境下相當明顯，惡意監聽節點仍能透過狀態更新時序，將前後產生的地址歸納至同一使用者。
BIP157 / BIP158 如何根本性改善查詢洩漏問題？
它顛倒了過濾方向。全節點不再被動接收使用者的過濾條件，而是向所有客戶端廣播全區塊的過濾數據，比對作業完全在使用者本機端進行，全節點無從得知哪些交易發生命中。
使用洋蔥網路（Tor）能否解決輕錢包的隱私疑慮？
Tor 僅能切斷網路傳輸層 IP 與請求者的直接對應。若錢包通訊協議本身仍會傳送精確的地址清單或低假陽性率的過濾器，伺服器依然能完整構建出錢包內各地址間的同屬關係。
