<div dir="ltr"><div class="gmail_extra">NACK: stated rationales are invalid: both privacy and DoS (see below for experimental data).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">1 - Bloom filtering doesn&#39;t add privacy for node operators, it adds privacy for lightweight wallets. And in fact, with a high FP rate it does do that. Most users want both low bandwidth usage <i><b>and</b></i> query scrambling, which is harder to do but not impossible. There is a clear roadmap for how to implement that with smarter clients: no protocol changes are needed. </div><div class="gmail_extra"><br></div><div class="gmail_extra">So the first stated rationale is spurious: disabling Bloom filtering doesn&#39;t improve privacy for anyone. It can only hurt.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">2 - SPV usage is rising, not falling.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Peter&#39;s data is flawed because he ignored the fact that SPV clients tend to connect, sync, then disconnect. They don&#39;t remain connected all the time. So merely examining a random snapshot of what&#39;s connected at a single point in time will give wildly varying and almost random results.</div><div class="gmail_extra"><br></div><div class="gmail_extra">A more scientifically valid approach is to check the number of actual connections over a long span of time. Here&#39;s the data from my node:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">mike@plan99:~/.bitcoin$ grep -Po &#39;receive version message: ([^:]*):&#39; debug.log |sort |uniq -c|sort -n|tac|head -n 10</div><div class="gmail_extra">  11027 receive version message: /<a href="http://getaddr.bitnodes.io" target="_blank">getaddr.bitnodes.io</a>:</div><div class="gmail_extra">   6264 receive version message: /bitcoinseeder:</div><div class="gmail_extra">   4944 receive version message: /bitcoinj:</div><div class="gmail_extra">   2531 receive version message: /Snoopy:</div><div class="gmail_extra">   2362 receive version message: /breadwallet:</div><div class="gmail_extra">   1127 receive version message: /Satoshi:</div><div class="gmail_extra">    204 receive version message: /Bitcoin XT:</div><div class="gmail_extra">    128 receive version message: /BitCoinJ:</div><div class="gmail_extra">     97 receive version message: /Bither1.3.8/:</div><div class="gmail_extra">     82 receive version message: /Bitaps:</div><div><br></div><div>Once crawlers are removed, SPV wallets (bitcoinj, breadwallet) make up the bulk of all P2P clients. This is very far from 1% and falling, as Todd wrongly suggests.</div><div><br></div><div><br></div><div><br></div><div>3 - It is said that there is a DoS attack possible. This claim does not seem to have been researched.</div><div><br></div><div>I decided to test it out for real, so I implemented a DoS attack similar to the one we&#39;ve seen against XT nodes: it sends getdata for large (1mb) filtered blocks over and over again as fast as possible.</div><div><br></div><div>As was reported and makes sense, CPU usage goes to 100%. However I couldn&#39;t see any other effects. RPCs still react immediately, the Qt GUI is fully responsive, I was even able to sync another SPV client to that node and it proceeded at full speed. It&#39;s actually pretty nice to see how well it held up.</div><div><br></div><div>Most importantly transactions and blocks continued to be relayed without delay. I saw my VPS node receive a block only eight seconds after my local node, which is well within normal propagation delays.</div><div><br></div><div>There&#39;s another very important point here: I profiled my local node whilst it was under this attack. It turns out that Bloom filtering is extremely fast. 90% of the CPU time is spent on loading and deserializing the data from disk. Only 10% of the CPU time was spent actually filtering.</div><div><br></div><div>Thus you can easily trigger exactly the same DoS attack by just using regular getdata requests on large blocks over and over. You don&#39;t need Bloom filtering. If you don&#39;t want to actually download the blocks just don&#39;t TCP ACK the packets and then FIN after a few seconds .... the data will all have been loaded and be sitting in the send buffers.</div><div><br></div><div>So even if I refine the attack and find a way to actually deny service to someone, the fix would have to apply to regular non-filtered block fetches too, which cannot be disabled.</div><div><br></div><div><br></div><div>In summary: this BIP doesn&#39;t solve anything, but does create a big upgrade headache.</div></div></div>