Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-21 📝 Original message:On Thu, Aug 20, 2015 at ...
📅 Original date posted:2015-08-21
📝 Original message: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 algorithm proposed in BIP 37, and
> > implemented in several clients today, has been shown to provide little
> > to no privacy, as well as being a large DoS risk on some nodes. Thus,
> > allowing node operators to disable connection bloom filtering is a
> > much-needed feature.
>
> I'd reference that paper on bloom filters re: the "little to no privacy"
> issue. There's also a post in the bitcoinj mailing list somewhere IIRC
> talking about the default settings, and how they don't provide any
> privacy.
Oh, and we should also point out that Bloom filters have scaling issues,
as each application of the filter has to scan the whole blockchain -
with future blocksize increases these issues increase, in some proposals
quite dramatically. The underlying idea also conflicts with some
proposals to "shard" the blockchain, again suggesting that we need a bit
to handle future upgrades to more scalable designs.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/17f5c150/attachment-0001.sig>;
📝 Original message: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 algorithm proposed in BIP 37, and
> > implemented in several clients today, has been shown to provide little
> > to no privacy, as well as being a large DoS risk on some nodes. Thus,
> > allowing node operators to disable connection bloom filtering is a
> > much-needed feature.
>
> I'd reference that paper on bloom filters re: the "little to no privacy"
> issue. There's also a post in the bitcoinj mailing list somewhere IIRC
> talking about the default settings, and how they don't provide any
> privacy.
Oh, and we should also point out that Bloom filters have scaling issues,
as each application of the filter has to scan the whole blockchain -
with future blocksize increases these issues increase, in some proposals
quite dramatically. The underlying idea also conflicts with some
proposals to "shard" the blockchain, again suggesting that we need a bit
to handle future upgrades to more scalable designs.
--
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/17f5c150/attachment-0001.sig>;