Quick question for you all:
Can you run a pruned node (pruned=1) while also having BIP158 compact block filters enabled (peerblockfilters=1 and blockfilterindex=1)?
Also, what’s the difference between BIP158 filters and Bloom filters (peerbloomfilters setting in bitcoin.conf)?
Running pruned nodes with peer block filters
5 replies 88 views
That's interesting question. I'll try it on my signet node and report the result a bit later.
Edit: I got this error message.
And when i reopen Bitcoin Qt (Signet) again without prune/filter, it currently redownload whole blockchain.
peerbloomfilters refer to BIP 37 which deemed to have broken privacy model.
It should be possible to patch Core to build the index in such a way that downloading of pruned blocks waits for the indexing to reach the current state before it starts discarding old blocks, according to this:
https://bitcoin.stackexchange.com/a/100146
HyperRavenFull Member
Posts: 175 · Reputation: 633
#4Jul 29, 2025, 06:30 AM
As per Bitcoin Core v0.22.0, you can run Bitcoin Core with pruned nodes, provided that you've indexed with those arguments during your initial synchronization.
Bloom filters are disabled by default quite a while ago, it was mostly used by SPV clients previously to retrieve transactions. Bloom filters consist of SPV clients constructing their own bloom filters and sending it to the client, while with BIP157, nodes serves filter to the SPV clients which can then request for the block once it identifies interested blocks. Other than the privacy concerns as highlighted above, you also have the resource concerns on the full node's side.
Thanks.
Would it also work if I started out without the pruned flag and added it later (culling disk space effectively)?
What about the case of a non-pruned node that's running with neither flag and then I restart it with block filters?
HyperRavenFull Member
Posts: 175 · Reputation: 633
#6Jul 29, 2025, 07:17 PM
The block filters are created during the synchronization phase. You would need to know the blocks as you are building the corresponding block filters, and block filters should not be generated upon request; they should be generated and kept locally to be served to the peers.
Hence, your block filter should be present after your IBD. You can prune after you've synchronized fully, or you can prune as you go. If you have a non-pruned node without block filter but decide to enable after, then you need to reindex as well to build it. Note that blockfilterindex provides for the filter and the peerblockfilters allows your peers know that you're able to service BIP157 and serve them the filters.
Related topics
- What's up with nodes keeping high relay fees? 16
- Bitcoin Core displaying coins (UTXOs) in a new tab 13
- Are you in favor of BIP-110? Let's get a Bitcoin poll going. 0
- Erlay seems to have some issues here’s a better proposal for a bitcoin protocol without invites 3
- New Optional Hourglass Implementation is Live 3
- Ways to earn some sats by contributing to bitcoin core development 5