From: Mike Hearn <mike@plan99•net>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom bait
Date: Wed, 11 Jun 2014 10:57:29 +0200 [thread overview]
Message-ID: <CANEZrP14gOCvWyDqJPEC=XRYMYKEXNi2AhN=FPw=jH+vR_vG-w@mail.gmail.com> (raw)
In-Reply-To: <20140610170846.GB21293@savin>
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
>
> Is this any different from my bloom filter IO attack code? Nope.
>
It's obviously different; a thin client trying to obtain more privacy is
not attempting to deny service to anyone. You can't simply state that a
feature which uses resources for a legitimate reason is a DoS attack,
that's a spurious definition that would reclassify innocuous things like
web browser prefetching as DoS attacks too.
With respect to the work you're proposing, trying to retroactively make
Bloom filtering an optional part of the protocol is just wasting people's
time at this point:
- There is no evidence there's an actual problem today.
- There is no evidence there will be a problem any time soon, given the
meagre levels of traffic growth we have.
- It involves a complicated rollout strategy that would create work for
many people.
- Gavin, Wladimir and myself have all concluded it's not worth the cost.
- The only justification you have provided is that two node
implementations hardly anyone uses can't be bothered to implement Bloom
filtering, but want to advertise support in their ver message anyway. They
can simply lower the number they advertise in their ver message.
That said, if you want to implement better support for archival nodes then
that'd be great. The way to do it would be either to implement block ranges
in the addr announcements as has been discussed many times before, or
perhaps introduce a new protocol optimised for serving the chain. Nodes
that are CPU limited won't want to take part in the rest of the P2P
protocol anyway, it's not just Bloom filtering that uses CPU time but also
block and tx relay.
But until you have done these things, please stop attempting to reclassify
any feature you can imagine a more efficient version of as an "attack".
It's just silly.
[-- Attachment #2: Type: text/html, Size: 2284 bytes --]
prev parent reply other threads:[~2014-06-11 8:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 8:19 [Bitcoin-development] NODE_BLOOM service bit Peter Todd
2014-06-06 8:48 ` Adam Back
2014-06-06 9:03 ` Gregory Maxwell
2014-06-06 9:11 ` Peter Todd
2014-06-06 9:04 ` Peter Todd
2014-06-06 10:45 ` Adam Back
2014-06-06 16:46 ` [Bitcoin-development] Bloom bait Peter Todd
2014-06-06 16:58 ` Gregory Maxwell
2014-06-06 17:05 ` Peter Todd
2014-06-06 17:10 ` Gregory Maxwell
2014-06-06 17:45 ` Peter Todd
2014-06-07 11:22 ` Mike Hearn
2014-06-07 19:44 ` Alan Reiner
2014-06-08 21:45 ` Peter Todd
2014-06-10 10:41 ` Mike Hearn
2014-06-08 21:35 ` Peter Todd
2014-06-10 10:38 ` Mike Hearn
2014-06-10 13:02 ` Jeff Garzik
2014-06-10 17:08 ` Peter Todd
2014-06-11 8:57 ` Mike Hearn [this message]
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='CANEZrP14gOCvWyDqJPEC=XRYMYKEXNi2AhN=FPw=jH+vR_vG-w@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/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