From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net,
Gregory Maxwell <gmaxwell@gmail.com>
Subject: [Bitcoin-development] NODE_BLOOM service bit
Date: Fri, 6 Jun 2014 04:19:33 -0400 [thread overview]
Message-ID: <20140606081933.GA29458@savin> (raw)
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
BIP: https://github.com/petertodd/bips/blob/bip-node-bloom/bip-node-bloom.mediawiki
Pull-req: https://github.com/bitcoin/bitcoin/pull/2900
Pretty simple really: service bit NODE_BLOOM is defined to allow nodes
to advertise to their peers that they support bloom filters. The network
protocol version number is also bumped. Recommended behavior for nodes
that do not support bloom is to simply disconnect peers who send a
filter* message anyway to let them quickly find another peer.
Rational: Bloom filters are not always supported or appropriate. For
instance no node implementation other than Bitcoin Core supports them,
e.g btcd and obelisk. (which ironically implement this BIP already,
modulo the version number bump) In the long term bloom filters will be
obsoleted eventually as they have poor scaling properties - problematic
with blocksize increases - and are incompatible with UTXO/TXO
commitments, which will use prefix-based filtering instead. (already
being implemented in electrum and obelisk)
In the short term bloom filters have high IO loads, which have lead to
DoS attacks, and are not an optimal use of resources for nodes which are
IO constrained rather than bandwidth constrained. (common in VPS setups
which could better help the network by serving full blocks)
Adding NODE_BLOOM as a service bit now will save us some hassle later
down the road, reflects what actual implementations do anyway, has been
already deployed on Litecoin, Dogecoin, and a zillion other alts with no
issues, (including SPV client support) and is a trivial patch.
Gregory Maxwell: Please assign a BIP #
--
'peter'[:-1]@petertodd.org
000000000000000049066dab2483c9e069656239f5782da204bd4995bd92c19f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next reply other threads:[~2014-06-06 8:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-06 8:19 Peter Todd [this message]
2014-06-06 8:48 ` [Bitcoin-development] NODE_BLOOM service bit Adam Back
2014-06-06 9:03 ` Gregory Maxwell
2014-06-06 9:11 ` Peter Todd
2014-06-06 9:04 ` Peter Todd
2014-06-06 10:45 ` Adam Back
2014-06-06 16:46 ` [Bitcoin-development] Bloom bait Peter Todd
2014-06-06 16:58 ` Gregory Maxwell
2014-06-06 17:05 ` Peter Todd
2014-06-06 17:10 ` Gregory Maxwell
2014-06-06 17:45 ` Peter Todd
2014-06-07 11:22 ` Mike Hearn
2014-06-07 19:44 ` Alan Reiner
2014-06-08 21:45 ` Peter Todd
2014-06-10 10:41 ` Mike Hearn
2014-06-08 21:35 ` Peter Todd
2014-06-10 10:38 ` Mike Hearn
2014-06-10 13:02 ` Jeff Garzik
2014-06-10 17:08 ` Peter Todd
2014-06-11 8:57 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140606081933.GA29458@savin \
--to=pete@petertodd.org \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=gmaxwell@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox