Solo Mining Calculator: Estimate Odds and Timeframes
Use a solo mining calculator correctly: enter productive hashrate, network conditions, uptime and time horizon, then read expected time and probability without.
Read article
ASIC mining knowledge centre
BIP 37 Bloom Filters Explained for Bitcoin Peer Connections
BIP 37 Bloom filters explained: review filtered-block relay, false positives, privacy leakage, resource risk and why modern clients moved away.
This guide explains BIP 37 Bloom filters 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 37 Bloom filters allowed a lightweight Bitcoin client to ask a full peer for transactions and merkle-block proofs likely to match its wallet. Probabilistic false positives were intended to obscure the exact interest set while reducing bandwidth.
- Why it matters: BIP 37 was an important lightweight-wallet milestone, but its server-side interest filters leak more information and consume more peer resources than the original intuition suggested. New systems should favour client-side compact filters or their own validating node, while legacy support is carefully bounded and tested.
- Current position: BIP 37 Bloom filters allowed a lightweight Bitcoin client to ask a full peer for transactions and merkle-block proofs likely to match its wallet.
What this means in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the proposal as giving each transaction a limited allowance of computer work. Simple operations use a little of that allowance and expensive operations use more. If a script uses the whole allowance, validation stops.
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.
The lightweight-client problem
A client that does not download every block still needs evidence that relevant transactions were confirmed. Asking a peer for exact addresses or outpoints reveals the wallet immediately. BIP 37 lets the client upload a probabilistic filter and receive matching transactions plus partial merkle proofs, reducing data compared with full blocks while attempting to add cover traffic.
Bloom filter properties
A Bloom filter is a bit field updated by several hash functions. It can say that an element is definitely absent or possibly present. False positives are expected; false negatives should not occur when construction and updates are correct. Filter size, number of hash functions and tweak influence the false-positive rate and resource cost.
Filterload and filtered blocks
A client sends filterload to install its filter, can add elements with filteradd and clear state with filterclear. It requests filtered blocks and receives merkleblock messages containing the block header, partial merkle tree and matched transaction identifiers, followed by relevant transactions. The client must validate proof of work, header chain and merkle reconstruction.
Why privacy was weaker than expected
Peers can combine filter contents, connection timing, requested history and later filter updates to infer wallet addresses and transaction graph. Low false-positive settings make matching more precise, while high rates increase bandwidth without guaranteeing anonymity. Connecting through several observers can spread rather than remove leakage when results are correlated.
Peer resource and abuse risk
Remote filters require a full node to scan transaction data and maintain per-peer state. Attackers can choose costly filters or repeatedly update them. Implementations added service flags, limits and eventually disabled serving by default in common configurations. A client must not assume that a random modern Bitcoin peer offers BIP 37.
Compact block filters as the newer model
BIP 157 and BIP 158 let servers provide deterministic compact filters for blocks. The client downloads filters and performs matching locally, so it does not upload its wallet interest set to each peer. It may then fetch relevant full blocks. This changes bandwidth and trust trade-offs but substantially improves query privacy.
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 BIP 37 Bloom Filters Explained for Bitcoin Peer Connections?
BIP 37 Bloom filters allowed a lightweight Bitcoin client to ask a full peer for transactions and merkle-block proofs likely to match its wallet. Probabilistic false positives were intended to obscure the exact interest set while reducing bandwidth.
Is BIP 37 Explained for Bitcoin Peer Connections active or supported today?
BIP 37 allowed a lightweight Bitcoin client to ask a full peer for transactions and merkle-block proofs likely to match its wallet.
Why does BIP 37 Explained for Bitcoin Peer Connections matter?
BIP 37 was an important lightweight-wallet milestone, but its server-side interest filters leak more information and consume more peer resources than the original intuition suggested. New systems should favour client-side compact filters or their own validating node, while legacy support is carefully bounded and tested.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
BIP 37 was an important lightweight-wallet milestone, but its server-side interest filters leak more information and consume more peer resources than the original intuition suggested. New systems should favour client-side compact filters or their own validating node, while legacy support is carefully bounded and tested.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
On this page
Search More Guides
BIP-110 Explained: Rules, Signalling and Why It Closed
BIP-110 Explained made simple. See the main facts, costs, risks and practical checks before you make a decision.
Read article
Bitcoin Core 29.4 Release: Chainstate Disk I/O Guide
Bitcoin Core 29.4 guide covering repeated chainstate rewrites, regular compaction, LevelDB seek compaction, transaction-data lifetime and wallet sizing fixes.
Read article
Need Advice for Your Mining Setup?
Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.