My draft is as follows. Gregory Maxwell: Can you assign a BIP # for this? The next number, 38, is on the wiki as "Passphrase-protected private key" by Mike Caldwell, although it isn't in the list so I don't know if that is official or not. BIP: ? Title: NODE_BLOOM service bit Author: Peter Todd Type: Standards Track (draft) Created: 17-08-2013 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. 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. There are however cases where a node may want to provide data, such as mempool transactions and blocks, but do not want to or have not implemented bloom filtering. Additionally it is good practice for nodes to be given options as to the granularity of the services they are providing the public - a full-node operator may be able to donate only a small amount of bandwidth and may want those efforts to be used by other full-node operators. Specification ============= The following protocol bit is added: NODE_BLOOM = (1 << 1) In addition the protocol version is increased from 70001 to 70002 in the reference implementation. Nodes that support bloom filters should set that protocol bit. Otherwise it should remain unset. NODE_BLOOM is distinct from NODE_NETWORK, and it is legal to advertise NODE_BLOOM but not NODE_NETWORK. 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. 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. Nodes that require the bloom filter service can set NODE_BLOOM for peers advertising a protocol version < 70002, allowing the rest of the implementation to be unchanged. Nodes with implementations that do not know of the NODE_BLOOM bit will be disconnected immediately as though the connection failed for some reason, and thus will not have incoming bandwidth wasted by that peer and can easily connect to another peer. Supporting NODE_BLOOM but not NODE_NETWORK allows for situations where a node may have data that its peers may be interested in, but is not a full node and thus does not have block data in general. For instance an SPV node that receives a full, unfiltered, block from a peer may want to let its SPV peers know about the existence of that block and provide them that data if requested. Those peers in turn may only be interested in knowing about the block if it matches a specific bloom filter. Note how in this example DoS attacks are made prohibitively expensive by the work required to create a valid block header. Reference Implementation ======================== https://github.com/bitcoin/bitcoin/pull/2900 Copyright ========= This document is placed in the public domain. -- 'peter'[:-1]@petertodd.org