每日8MB：比特幣靜默支付面臨資料遺漏挑戰

比特幣(BTC)靜默支付所需的行動掃描資料，近期區段估計每日約8.0MB；但若遠端伺服器遺漏部分交易資料，錢包即使完成同步，也可能找不到入帳紀錄。

CryptoSlate於15日介紹一項分析255,434個比特幣區塊的測量結果，估計BlindBit Oracle v2完整掃描資料流每日約需8.0MB。這是套用每日144個區塊計算出的近期區段平均值，與首次下載過去全部資料所需的容量不同。

靜默支付的設計是，即使使用者公開一個固定地址，每筆實際收款交易仍會衍生新的Taproot地址。付款方利用收款方的公開資訊建立目的地，收款方錢包則結合交易輸入資訊與掃描金鑰，找出屬於自己的輸出。

BIP-352指出，這種方式可減少因地址重複使用造成的鏈上交易關聯。不過，如何支援不直接處理區塊鏈的輕客戶端，仍是需要進一步研究的領域。

若行動錢包不直接處理整條區塊鏈，就必須從索引器或遠端掃描器取得每筆交易的公開資料「tweak」。一旦伺服器遺漏特定tweak，錢包便無法找到有效的入帳輸出，使用者畫面可能因此顯示沒有入帳。

記錄在區塊鏈上的輸出本身並不會消失。問題在於，錢包可能因未取得搜尋該輸出所需的資料，即使顯示同步完成，也無法察覺遺漏。

此次測量範圍為區塊高度709,656至965,089。完整BlindBit v2掃描資料合計15,079,946,729位元組，約15.08GB；每個區塊平均資料量為59.0KB。

上述數值代表復原整段測量期間所需的容量。每日8.0MB的估計值，則是把近期區段平均值套用至每日區塊數，因此兩者不能以相同基準直接比較。

降低資料傳輸量的方法之一，是結合Taproot專用過濾器與raw tweak。累積資料量估計約7.14GB，但仍須額外下載符合過濾器的區塊，實際通訊量會受錢包活動與誤判率影響。

過濾器計算公式與21個實際過濾器編碼相比，誤差約在0.5%以內。不過，目前尚未確認該過濾器已實際部署。

若要驗證資料完整性，需要由多個伺服器公開各區塊tweak集合的承諾值並相互比對。BIP-352索引伺服器規格草案提出自行營運節點與索引器、使用遠端掃描器等多種架構，但該文件仍在制定中。

相關實作已擴展至部分錢包。Sparrow Wallet 2.5.0新增靜默支付收款與硬體錢包支援，並會自動選擇Frigate作為相關公開Electrum伺服器。

BlindBit Oracle v2是提供靜默支付資料的索引伺服器，支援HTTP與gRPC API。另一方面，靜默支付開發文件將Frigate列為實驗性Electrum伺服器，並說明相關輕客戶端規格仍在制定中。

過去Cake Wallet的問題紀錄曾提出，錢包在收到不完整資料後若儲存較高的掃描高度，即使改用其他伺服器，也可能不會重新請求遺漏區段。該問題中記錄了一個從較早區塊重新掃描後，靜默支付入帳紀錄出現的案例。

目前尚未確認有針對此次測量的獨立營運者重現結果。因此，15.08GB與每日8.0MB目前仍應視為單一測量結果；行動錢包的收款穩定性，後續仍需連同資料容量、遺漏偵測與重新掃描架構一併驗證。