{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-24\n📝 Original message:NACK: stated rationales are invalid: both privacy and DoS (see below for\nexperimental data).\n\n\n1 - Bloom filtering doesn't add privacy for node operators, it adds privacy\nfor lightweight wallets. And in fact, with a high FP rate it does do that.\nMost users want both low bandwidth usage *and* query scrambling, which is\nharder to do but not impossible. There is a clear roadmap for how to\nimplement that with smarter clients: no protocol changes are needed.\n\nSo the first stated rationale is spurious: disabling Bloom filtering\ndoesn't improve privacy for anyone. It can only hurt.\n\n\n\n2 - SPV usage is rising, not falling.\n\nPeter's data is flawed because he ignored the fact that SPV clients tend to\nconnect, sync, then disconnect. They don't remain connected all the time.\nSo merely examining a random snapshot of what's connected at a single point\nin time will give wildly varying and almost random results.\n\nA more scientifically valid approach is to check the number of actual\nconnections over a long span of time. Here's the data from my node:\n\nmike at plan99:~/.bitcoin$ grep -Po 'receive version message: ([^:]*):'\ndebug.log |sort |uniq -c|sort -n|tac|head -n 10\n  11027 receive version message: /getaddr.bitnodes.io:\n   6264 receive version message: /bitcoinseeder:\n   4944 receive version message: /bitcoinj:\n   2531 receive version message: /Snoopy:\n   2362 receive version message: /breadwallet:\n   1127 receive version message: /Satoshi:\n    204 receive version message: /Bitcoin XT:\n    128 receive version message: /BitCoinJ:\n     97 receive version message: /Bither1.3.8/:\n     82 receive version message: /Bitaps:\n\nOnce crawlers are removed, SPV wallets (bitcoinj, breadwallet) make up the\nbulk of all P2P clients. This is very far from 1% and falling, as Todd\nwrongly suggests.\n\n\n\n3 - It is said that there is a DoS attack possible. This claim does not\nseem to have been researched.\n\nI decided to test it out for real, so I implemented a DoS attack similar to\nthe one we've seen against XT nodes: it sends getdata for large (1mb)\nfiltered blocks over and over again as fast as possible.\n\nAs was reported and makes sense, CPU usage goes to 100%. However I couldn't\nsee any other effects. RPCs still react immediately, the Qt GUI is fully\nresponsive, I was even able to sync another SPV client to that node and it\nproceeded at full speed. It's actually pretty nice to see how well it held\nup.\n\nMost importantly transactions and blocks continued to be relayed without\ndelay. I saw my VPS node receive a block only eight seconds after my local\nnode, which is well within normal propagation delays.\n\nThere's another very important point here: I profiled my local node whilst\nit was under this attack. It turns out that Bloom filtering is extremely\nfast. 90% of the CPU time is spent on loading and deserializing the data\nfrom disk. Only 10% of the CPU time was spent actually filtering.\n\nThus you can easily trigger exactly the same DoS attack by just using\nregular getdata requests on large blocks over and over. You don't need\nBloom filtering. If you don't want to actually download the blocks just\ndon't TCP ACK the packets and then FIN after a few seconds .... the data\nwill all have been loaded and be sitting in the send buffers.\n\nSo even if I refine the attack and find a way to actually deny service to\nsomeone, the fix would have to apply to regular non-filtered block fetches\ntoo, which cannot be disabled.\n\n\nIn summary: this BIP doesn't solve anything, but does create a big upgrade\nheadache.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150824/ece22a74/attachment.html\u003e"}