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
As I explained in the email you're replying to and didn't quote, bloom
filters has O(n) cost per query, so sending different bloom filters to
different peers for privacy reasons costs the network significant disk
IO resources. If I were to actually implement it it'd look like a DoS
attack on
A NODE_BLOOM service bit is a very reasonable
and simple way to do exactly that, and is defacto what implementations
that don't support bloom filters do anyway.
BTW, I find it curious that any nodes have code to disconnect peers that
send Bloom filters. It shouldn't be necessary. Bitcoinj
Most of this description of disk activity is true, but it omits one
key point: Total cached data (working set). It is a binary, first
order question: are you hitting pagecache, or the disk? When nodes
act as archival data sources, the pagecache pressure is immense. When
nodes just primarily
On Tue, Jun 10, 2014 at 06:38:23PM +0800, Mike Hearn wrote:
As I explained in the email you're replying to and didn't quote, bloom
filters has O(n) cost per query, so sending different bloom filters to
different peers for privacy reasons costs the network significant disk
IO resources.
On Sat, Jun 07, 2014 at 07:22:56PM +0800, Mike Hearn wrote:
You can send different bloom filters to different peers too, so I'm not
sure why you're listing subsetting as a unique advantage of prefix filters.
As I explained in the email you're replying to and didn't quote, bloom
filters has O(n)
On Sat, Jun 07, 2014 at 03:44:07PM -0400, Alan Reiner wrote:
On 06/07/2014 07:22 AM, Mike Hearn wrote:
You can send different bloom filters to different peers too, so I'm
not sure why you're listing subsetting as a unique advantage of prefix
filters.
Please let me know if we've
On 06/07/2014 07:22 AM, Mike Hearn wrote:
You can send different bloom filters to different peers too, so I'm
not sure why you're listing subsetting as a unique advantage of prefix
filters.
Please let me know if we've gone down this path before, but it would
seem that the more different
On Fri, Jun 06, 2014 at 12:45:43PM +0200, Adam Back wrote:
(changed subject line as this discussion has nothing to do with
NODE_BLOOM)
As I recall prefix brute forcing was a bit twiddle saving, ie searching for
EDH key that has the users public prefix. That does not improve privacy
over an
On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd p...@petertodd.org wrote:
transactions against. Where they differ is that bloom filters has O(n)
scaling, where n is the size of a block, and prefix filters have O(log n)
scaling with slightly(1) higher k. Again, if you *don't* use brute forcing
in
On Fri, Jun 06, 2014 at 09:58:19AM -0700, Gregory Maxwell wrote:
On Fri, Jun 6, 2014 at 9:46 AM, Peter Todd p...@petertodd.org wrote:
transactions against. Where they differ is that bloom filters has O(n)
scaling, where n is the size of a block, and prefix filters have O(log n)
scaling with
On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd p...@petertodd.org wrote:
Again, you *don't* have to use brute-force prefix selection. You can
just as easily give your peer multiple prefixes, each of which
corresponds at least one address in your wallet with some false positive
rate. I explained
On Fri, Jun 06, 2014 at 10:10:51AM -0700, Gregory Maxwell wrote:
On Fri, Jun 6, 2014 at 10:05 AM, Peter Todd p...@petertodd.org wrote:
Again, you *don't* have to use brute-force prefix selection. You can
just as easily give your peer multiple prefixes, each of which
corresponds at least one
13 matches
Mail list logo
