公鑰及其對應的雜湊值是否都添加到了 BitcoinJ Bloom 過濾器中？

論文《關於輕量級比特幣客戶端中布隆過濾器的隱私條款》對SPV 中的布隆過濾器有這樣的說法：

…事實上，在 SPV 客戶端 [BitcoinJ] 的目前實現中，地址及其公鑰都插入到外包的 Bloom 過濾器中。因此，如果攻擊者知道地址和它的公鑰，那麼她可以通過檢查地址和它的公鑰是否都插入到過濾器中來簡單地測試一個地址是否是過濾器的真陽性。如果不是，那麼該地址很可能是過濾器的誤報。我們認為，在 Bloom 過濾器中同時包含地址及其公鑰是目前 SPV 客戶端實現中的一個嚴重缺陷，並且可以輕鬆應對; 因此，我們不會在分析中利用這個缺陷。事實上，超過 99% 的比特幣交易包括對比特幣地址（或公鑰雜湊）的支付；此外，系統中 3300 萬個地址中只有 4587 個收到了以它們的公鑰和公鑰散列為目標的交易。這意味著對於絕大多數比特幣客戶來說，沒有必要在 Bloom 過濾器中同時包含公鑰和它們的雜湊值（即比特幣地址）；插入其中一個就足夠了（在超過 99% 的情況下）。[我的重點]

此次攻擊背後的想法在 BitcoinJ 的隱私中得到了重申：

漏洞在於，如果 pubkey 確實在過濾器中，那麼查詢 pubkey 和 pubkeyhash 必須返回 true。因為 pubkeyhash 只是另一個幾乎均勻隨機的字元串，所以攻擊者誤報的機率是 fp’ = fp^2 = 0.0000000021555。我從區塊鏈（1 月中旬）獲得了大約 5600 萬個 pubkey，理論上在掃描區塊鏈時會導致 5600 萬 * fp’ = 1.29 的預期誤報。

換句話說，一個簡單的攻擊就足以從 BitcoinJ Bloom 過濾器中挑選出所有的公鑰。

目前版本的 BitcoinJ 是否將公鑰及其雜湊值添加到其 Bloom 過濾器中？如果沒有，哪個版本阻止了它的發生？

另外，為什麼首先要同時添加公鑰和雜湊？

目前版本的 BitcoinJ 是否將公鑰及其雜湊值添加到其 Bloom 過濾器中？如果沒有，哪個版本阻止了它的發生？

是的。下面的程式碼實現它：

/** Inserts the given key and equivalent hashed form (for the address). */
public synchronized void insert(ECKey key) {
   insert(key.getPubKey());
   insert(key.getPubKeyHash());
}

（資源。）

另外，為什麼首先要同時添加公鑰和雜湊？

我不是寫這篇文章的人（Mike Hearn）。話雖如此，我猜很難判斷一個地址的存款是 P2PKH 還是 P2PK 形式。支付公鑰確實不常見，但它是合法的。考慮到讓他的一些客戶的錢因神秘原因失去或減少他們的隱私之間的選擇，他選擇了後者。

現在，如果您問為什麼filterload不在將密鑰的 HASH160 與布隆過濾器進行比較之前獲取密鑰的 HASH160，以便瘦客戶端可以同時查找雜湊和密鑰，我不知道。這似乎可以在相當合理的 CPU 時間內解決該論文中提到的問題。我會責怪BIP37的作者，但那是同一個人寫的。

引用自：https://bitcoin.stackexchange.com/questions/37756