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
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
> off
> > glob
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.
On 08/24/15 18:15, Eric Lombrozo 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.
I'm not sure what your reasoning for this is? If your concern is that
someone starts DoS attacking you with bloom-
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
and
BIP 111 was assigned, pull request (with the proposed changes) available
at https://github.com/bitcoin/bips/pull/183
Matt
On 08/24/15 18:00, Peter Todd wrote:
> On Mon, Aug 24, 2015 at 05:37:51PM +, Matt Corallo via bitcoin-dev wrote:
>> Its more of a statement of "in the future, we expect th
On Mon, Aug 24, 2015 at 05:37:51PM +, Matt Corallo via bitcoin-dev wrote:
> 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
> dis
When I was working on mSIGNA I became a little torn on the whole filtering
mechanism. I fully support connection filtering...but in practice always
run my own full node instances to connect to due to the three fatal flaws:
1) no mechanism for short proofs of tx nonexclusion, txout unspentness,
bloc
On Mon, Aug 24, 2015 at 05:37:51PM +, Matt Corallo wrote:
> 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_
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 wa
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
> 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
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
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 re
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 kn
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, b
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 t
On 8/20/2015 11:07 PM, Peter Todd via bitcoin-dev wrote:
> I run a number of high speed nodes and while I don't have historical
> logs handy over time, I've noticed a drop from about %5-%10 SPV
> clients at any one time tocloser to %1
Just checked mine and found 20.4% bitcoinj connections.
___
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 go
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.
Relate
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
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 AS
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 whic
On 08/21/2015 07:55 AM, Peter Todd via bitcoin-dev wrote:
> 2) Bloom filter usage has declined significantly, as lite-SPV clients
> are moving towards using centralized, trusted, servers run by the wallet
> authors. For instance
> [Mycelium](https://github.com/mycelium-com/wallet),
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 hi
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 wrote:
> On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via bitcoin-dev
> wro
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 h
If this is widely deployed + enabled, what is the impact to current wallets
in use?
On Fri, Aug 21, 2015 at 12:46 AM, Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Peter: Since I stole most of this text from your old BIP, should I leave
> you as an author?
>
> BI
On Thu, Aug 20, 2015 at 10:38:19PM -0700, Peter Todd via bitcoin-dev wrote:
> > Motivation
> > ==
> >
> > BIP 37 did not specify a service bit for the bloom filter service, thus
> > implicitly assuming that all nodes that serve peers data support it.
> > However, the connection filtering a
On Fri, Aug 21, 2015 at 04:46:17AM +, Matt Corallo wrote:
> Peter: Since I stole most of this text from your old BIP, should I leave
> you as an author?
That's fine by me.
> BIP: ?
> Title: NODE_BLOOM service bit
> Author: Matt Corallo , Peter Todd
> Type: Standards Track (draft)
> Created:
Peter: Since I stole most of this text from your old BIP, should I leave
you as an author?
BIP: ?
Title: NODE_BLOOM service bit
Author: Matt Corallo , Peter Todd
Type: Standards Track (draft)
Created: 20-08-2015
Abstract
This BIP extends BIP 37, Connection Bloom filtering, by defining
30 matches
Mail list logo
