From: Mike Hearn <hearn@vinumeris•com>
To: Tom Harding <tomh@thinlink•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP
Date: Mon, 24 Aug 2015 17:21:47 +0200 [thread overview]
Message-ID: <CA+w+GKSy5oEy-pS_JsoaGBEp3Fn=x5HZSiFAEVnmkQi5=qhP5Q@mail.gmail.com> (raw)
In-Reply-To: <55D7AF85.2020707@thinlink.com>
[-- Attachment #1: Type: text/plain, Size: 3513 bytes --]
NACK: stated rationales are invalid: both privacy and DoS (see below for
experimental data).
1 - Bloom filtering doesn'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 *and* 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.
So the first stated rationale is spurious: disabling Bloom filtering
doesn't improve privacy for anyone. It can only hurt.
2 - SPV usage is rising, not falling.
Peter's data is flawed because he ignored the fact that SPV clients tend to
connect, sync, then disconnect. They don't remain connected all the time.
So merely examining a random snapshot of what's connected at a single point
in time will give wildly varying and almost random results.
A more scientifically valid approach is to check the number of actual
connections over a long span of time. Here's the data from my node:
mike@plan99:~/.bitcoin$ grep -Po 'receive version message: ([^:]*):'
debug.log |sort |uniq -c|sort -n|tac|head -n 10
11027 receive version message: /getaddr.bitnodes.io:
6264 receive version message: /bitcoinseeder:
4944 receive version message: /bitcoinj:
2531 receive version message: /Snoopy:
2362 receive version message: /breadwallet:
1127 receive version message: /Satoshi:
204 receive version message: /Bitcoin XT:
128 receive version message: /BitCoinJ:
97 receive version message: /Bither1.3.8/:
82 receive version message: /Bitaps:
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.
3 - It is said that there is a DoS attack possible. This claim does not
seem to have been researched.
I decided to test it out for real, so I implemented a DoS attack similar to
the one we've seen against XT nodes: it sends getdata for large (1mb)
filtered blocks over and over again as fast as possible.
As was reported and makes sense, CPU usage goes to 100%. However I couldn'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's actually pretty nice to see how well it held
up.
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.
There'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.
Thus you can easily trigger exactly the same DoS attack by just using
regular getdata requests on large blocks over and over. You don't need
Bloom filtering. If you don't want to actually download the blocks just
don'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.
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.
In summary: this BIP doesn't solve anything, but does create a big upgrade
headache.
[-- Attachment #2: Type: text/html, Size: 4798 bytes --]
next prev parent reply other threads:[~2015-08-24 15:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 4:46 Matt Corallo
2015-08-21 5:38 ` Peter Todd
2015-08-21 5:42 ` Peter Todd
2015-08-21 17:55 ` Matt Corallo
2015-08-21 22:06 ` Peter Todd
2015-08-22 1:08 ` Matt Corallo
2015-08-22 1:48 ` Peter Todd
2015-08-24 15:19 ` Tom Harding
2015-08-24 17:39 ` Matt Corallo
2015-08-22 1:08 ` Matt Corallo
2015-08-21 5:48 ` Jeff Garzik
2015-08-21 5:55 ` Peter Todd
2015-08-21 6:01 ` Jeff Garzik
2015-08-21 6:07 ` Peter Todd
2015-08-21 22:15 ` Chris Pacia
2015-08-21 22:25 ` Peter Todd
2015-08-21 23:08 ` Tom Harding
2015-08-24 15:21 ` Mike Hearn [this message]
2015-08-21 8:31 ` Andreas Schildbach
2015-08-21 17:53 ` Matt Corallo
2015-08-24 15:29 ` Wladimir J. van der Laan
2015-08-24 17:37 ` Matt Corallo
2015-08-24 17:41 ` Wladimir J. van der Laan
2015-08-24 17:58 ` Eric Lombrozo
2015-08-24 18:00 ` Peter Todd
2015-08-24 18:07 ` Matt Corallo
2015-08-24 18:15 ` Eric Lombrozo
2015-08-24 18:28 ` Matt Corallo
2015-08-24 18:30 ` Wladimir J. van der Laan
2015-08-24 18:33 ` Eric Lombrozo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+w+GKSy5oEy-pS_JsoaGBEp3Fn=x5HZSiFAEVnmkQi5=qhP5Q@mail.gmail.com' \
--to=hearn@vinumeris$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomh@thinlink$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox