rich1.0npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58https://nostr.ae/npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58njumphttps://nostr.ae📅 Original date posted:2015-08-21 📝 Original message: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 at lists.linuxfoundation.org> wrote: > 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 <bip at bluematt.me>, Peter Todd <pete at petertodd.org> > Type: Standards Track (draft) > Created: 20-08-2015 > > Abstract > ======== > > This BIP extends BIP 37, Connection Bloom filtering, by defining a > service bit to allow peers to advertise that they support bloom filters > explicitly. It also bumps the protocol version to allow peers to > identify old nodes which allow bloom filtering of the connection despite > lacking the new service bit. > > > 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. > > > Specification > ============= > > The following protocol bit is added: > > NODE_BLOOM = (1 << 2) > > Nodes which support bloom filters should set that protocol bit. > Otherwise it should remain unset. In addition the protocol version is > increased from 70002 to 70011 in the reference implementation. It is > often the case that nodes which have a protocol version smaller than > 70011, but larger than 70000 support bloom filtered connections without > the NODE_BLOOM bit set, however clients which require bloom filtered > connections should avoid making this assumption. > > 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). > > If a node does not support bloom filters but receives a "filterload", > "filteradd", or "filterclear" message from a peer the node should > disconnect that peer immediately. For backwards compatibility, in > initial implementations, nodes may choose to only disconnect nodes which > have the new protocol version set and attempt to send a filter command. > > While outside the scope of this BIP it is suggested that DNS seeds and > other peer discovery mechanisms support the ability to specify the > services required; current implementations simply check only that > NODE_NETWORK is set. > > > Design rational > =============== > > A service bit was chosen as applying a bloom filter is a service. > > The increase in protocol version is for backwards compatibility. In > initial implementations, old nodes which are not yet aware of NODE_BLOOM > and use a protocol version < 70011 may still send filter* messages to a > node without NODE_BLOOM. This feature may be removed after there are > sufficient NODE_BLOOM nodes available and SPV clients have upgraded, > allowing node operators to fully close the bloom-related DoS vectors. > > > Reference Implementation > ======================== > > https://github.com/bitcoin/bitcoin/pull/6579 > > > Copyright > ========= > > This document is placed in the public domain. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/fa23e4e1/attachment.html>