Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£861.31
EST. MONTHLY
205
DAYS
EST. ROI
This guide explains BIP 111 NODE_BLOOM service bit in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 111 defines NODE_BLOOM, the service bit get by shifting one left by two positions, so a Bitcoin peer can explicitly advertise support for BIP 37 connection Bloom filtering. It also associated the transition with protocol version 70011.
- Why it matters: BIP 111 gave an optional and risky peer service an explicit capability boundary. Operators should respect that signal, limit legacy support and prefer wallet designs that do not reveal their interest filter to arbitrary peers.
- Current position: Where a proposal is closed or draft, isolate its parser and experimental code from production.
BIP 111 NODE_BLOOM service bit in simple English
BIP 111 NODE_BLOOM service bit: A supporting node sets bit two in the services field exchanged during peer connection setup. NODE_BLOOM is independent of NODE_NETWORK, although advertising Bloom support without general block service had little immediate use.
Simple example
A node operator is checking BIP 111 NODE_BLOOM service bit. BIP 111 made the optional service discoverable, allowing clients to choose a capable peer and allowing full-node operators to disable the work clearly.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Why an explicit service bit was needed
BIP 37 originally implied that peers serving general network data also supported connection Bloom filters. Research and operational experience showed weak privacy and denial-of-service exposure. BIP 111 made the optional service discoverable, allowing clients to choose a capable peer and allowing full-node operators to disable the work clearly.
NODE_BLOOM on the wire
A supporting node sets bit two in the services field exchanged during peer connection setup. NODE_BLOOM is independent of NODE_NETWORK, although advertising Bloom support without general block service had little immediate use. Software must inspect the bit rather than infer capability from a product name, address or familiar user agent.
Protocol version 70011 transition
The reference implementation increased its protocol version from 70002 to 70011. Some older peers between 70000 and 70010 supported filtering despite lacking the new bit, but the BIP advised clients not to depend on that assumption. Version heuristics were a migration aid, not durable capability negotiation.
Unsupported filter messages
A node that does not support Bloom filters should disconnect a peer sending filterload, filteradd or filterclear. Early implementations could apply a compatibility exception to old-version peers. Operators need rate limits and clear disconnect telemetry because unsupported service requests are peer-controlled input, not evidence that the local validator is unhealthy.
Privacy and resource boundary
A remote Bloom filter exposes a probabilistic description of wallet interests, which observers can correlate with requests and updates. Serving it also consumes CPU, memory and historical transaction access. False positives do not create a reliable anonymity guarantee, and increasing them can increase resource use without defeating a determined observer.
Modern client alternatives
BIP 157 and BIP 158 move matching to the client by distributing compact filters for each block. A wallet can check locally and request relevant blocks, rather than uploading its address interest set. A privately controlled validating node offers another model. Neither migration path should silently fall back to an unadvertised legacy service.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of BIP 111 NODE_BLOOM service bit?
BIP 111 NODE_BLOOM service bit: A supporting node sets bit two in the services field exchanged during peer connection setup.
For BIP 111 NODE_BLOOM service bit, why an explicit service bit was needed?
BIP 37 originally implied that peers serving general network data also supported connection Bloom filters.
For BIP 111 NODE_BLOOM service bit, what should a beginner know about node_bloom on the wire?
A supporting node sets bit two in the services field exchanged during peer connection setup.
For BIP 111 NODE_BLOOM service bit, what should a beginner know about protocol version 70011 transition?
The reference implementation increased its protocol version from 70002 to 70011. Some older peers between 70000 and 70010 supported filtering despite lacking the new bit, but the BIP advised clients not to depend on that assumption.
Conclusion
BIP 111 gave an optional and risky peer service an explicit capability boundary. Operators should respect that signal, limit legacy support and prefer wallet designs that do not reveal their interest filter to arbitrary peers.
Primary sources
- BIP 111 NODE_BLOOM service bit
- BIP 37 Connection Bloom filtering
- BIP 157 Client Side Block Filtering
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.