diff options
-rw-r--r-- | README.mediawiki | 6 | ||||
-rw-r--r-- | bip-0066.mediawiki | 2 | ||||
-rw-r--r-- | bip-0067.mediawiki | 4 | ||||
-rw-r--r-- | bip-0101.mediawiki | 2 | ||||
-rw-r--r-- | bip-0111.mediawiki | 85 |
5 files changed, 95 insertions, 4 deletions
diff --git a/README.mediawiki b/README.mediawiki index 041a4f1..1f29958 100644 --- a/README.mediawiki +++ b/README.mediawiki @@ -289,6 +289,12 @@ Those proposing changes should consider that ultimately consent may rest with th | Gavin Andresen | Standard | Draft +|- +| [[bip-0111.mediawiki|111]] +| NODE_BLOOM service bit +| Matt Corallo and Peter Todd +| Standard +| Draft |} <!-- IMPORTANT! See the instructions at the top of this page, do NOT JUST add BIPs here! --> diff --git a/bip-0066.mediawiki b/bip-0066.mediawiki index 41cbd8f..1235afd 100644 --- a/bip-0066.mediawiki +++ b/bip-0066.mediawiki @@ -2,7 +2,7 @@ BIP: 66 Title: Strict DER signatures Author: Pieter Wuille <pieter.wuille@gmail.com> - Status: Draft + Status: Final Type: Standards Track Created: 2015-01-10 </pre> diff --git a/bip-0067.mediawiki b/bip-0067.mediawiki index 9c4f3de..8be5c9b 100644 --- a/bip-0067.mediawiki +++ b/bip-0067.mediawiki @@ -4,8 +4,8 @@ Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft - Type: Standard - Created: 8 February 2015 + Type: Standards Track + Created: 2015-02-08 </pre> ==Abstract== diff --git a/bip-0101.mediawiki b/bip-0101.mediawiki index 9a78255..a76db0f 100644 --- a/bip-0101.mediawiki +++ b/bip-0101.mediawiki @@ -44,7 +44,7 @@ Expressed in pseudo-code, using integer math, assuming that block_timestamp is a Deployment shall be controlled by hash-power supermajority vote (similar to the technique used in BIP34), but the earliest possible activation time is 2016-01-11 00:00:00 UTC. -Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with bits 1,2,3 and 14 set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC. +Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex). The activation time will be the timestamp of the 750'th block plus a two week (1,209,600 second) grace period to give any remaining miners or services time to upgrade to support larger blocks. If a supermajority is achieved more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 00:00:00 UTC. Block version numbers are used only for activation; once activation is achieved, the maximum block size shall be as described in the specification section, regardless of the version number of the block. diff --git a/bip-0111.mediawiki b/bip-0111.mediawiki new file mode 100644 index 0000000..d3bd630 --- /dev/null +++ b/bip-0111.mediawiki @@ -0,0 +1,85 @@ +<pre> + BIP: 111 + Title: NODE_BLOOM service bit + Author: Matt Corallo <bip@bluematt.me>, Peter Todd <pete@petertodd.org> + Status: Draft + Type: Standards Track + Created: 2015-08-20 +</pre> + +== 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<ref>http://eprint.iacr.org/2014/763</ref>, as well as being a large DoS risk on some nodes<ref>[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-July/003044.html] is one example where the issues were found, though others independently discovered issues as well. Sample DoS exploit code available at https://github.com/petertodd/bloom-io-attack.</ref>. +Thus, allowing node operators to disable connection bloom filtering is a +much-needed feature. + + +== Specification == + +The following protocol bit is added: + +<pre> + NODE_BLOOM = (1 << 2) +</pre> + +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 (though there is little reason to do +so now, some proposals may make this more useful in the future) + +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. + + +== References == +<references> |