NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise
NODE_BLOOM but not NODE_NETWORK (eg for nodes running in pruned mode
which, nonetheless, provide filtered access to the data which they do have).
But is this useful without having decided on a way to signal which blocks
On 8/21/2015 3:06 PM, Peter Todd via bitcoin-dev wrote:
On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
Anyone have the best reference for the DoS issues?
Well actually, we can reference the DoS attacks that Bitcoin XT nodes
are undergoing right now - part of the attack is
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
I'll just quote what I said on github:
Neither this pull nor the BIP has any stated intention of phasing out
bloom filtering support in the protocol. As much as I'd love to, I 100%
agree with @mikehearn here, that would break any ability of SPV clients
to operate on the P2P network (either as a
Its more of a statement of in the future, we expect things to happen
which would make this an interesting thing to do, so we state here that
it is not against spec to do so. Could reword it as NODE_BLOOM is
distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM but
not NODE_NETWORK
On Mon, Aug 24, 2015 at 06:15:39PM +, Eric Lombrozo via bitcoin-dev wrote:
It would be very useful to not only be able to switch filtering on and off
globally...but to be able to switch on a per-connection basis. But then
You don't necessarily need to send everyone the same nServices bits.
It would be very useful to not only be able to switch filtering on and off
globally...but to be able to switch on a per-connection basis. But then
again, perhaps it would be smarter to ditch the whole bloom filter thing in
favor of an actual client/server architecture with proper authentication
Indeed, so I don't really have a problem with this proposal.
On Mon, Aug 24, 2015, 11:30 AM Wladimir J. van der Laan laa...@gmail.com
wrote:
On Mon, Aug 24, 2015 at 06:15:39PM +, Eric Lombrozo via bitcoin-dev
wrote:
It would be very useful to not only be able to switch filtering on and
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
decided against it...still, I think we should add the option to select
service bits to DNS seeds
The proposal will not break any existing clients in the first release.
After sufficient time to upgrade SPV clients, a new version will be
released which will result in older SPV clients finding themselves
disconnected from peers when they send filter* commands, so they can go
find other peers
On Fri, Aug 21, 2015 at 06:15:16PM -0400, Chris Pacia wrote:
On Aug 21, 2015 2:07 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Also, as I mentioned, just look at the popularity of wallets such as
Mycelium that are not adopting bloom filters, but going with
On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
decided against it...still, I
On Aug 21, 2015 2:07 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Also, as I mentioned, just look at the popularity of wallets such as
Mycelium that are not adopting bloom filters, but going with SPV
verification of block headers w/ lookup servers.
Related I
BIP Editor: Can I get a BIP # for this?
On 08/21/15 17:55, Matt Corallo via bitcoin-dev wrote:
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
On Sat, Aug 22, 2015 at 01:08:13AM +, Matt Corallo wrote:
Well actually, we can reference the DoS attacks that Bitcoin XT nodes
are undergoing right now - part of the attack is repeated Bloom filter
requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far
as I know they
On 08/21/15 22:06, Peter Todd wrote:
On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this
On Fri, Aug 21, 2015 at 02:01:06AM -0400, Jeff Garzik wrote:
I don't see any link to data backing up Bloom filter usage has declined
significantly
Is there actual data showing this feature's use is declining or
non-existent?
I run a number of high speed nodes and while I don't have
I don't see any link to data backing up Bloom filter usage has declined
significantly
Is there actual data showing this feature's use is declining or
non-existent?
On Fri, Aug 21, 2015 at 1:55 AM, Peter Todd p...@petertodd.org wrote:
On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via
On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via bitcoin-dev wrote:
If this is widely deployed + enabled, what is the impact to current wallets
in use?
See my comment on the recently-opened issue, reproduced below. In short,
not all that much, especially if we adopt my suggestion of
19 matches
Mail list logo
