Pruned node + peer block filters

[NotATether]

Just a simple question:

Is it possible to run a pruned node (pruned=1) alongside BIP158 compact block filters support (peerblockfilters=1 and blockfilterindex=1)?

And how are BIP158 filters different from Bloom filters (peerbloomfilters setting in bitcoin.conf)?

[ABCbits]

Is it possible to run a pruned node (pruned=1) alongside BIP158 compact block filters support (peerblockfilters=1 and blockfilterindex=1)?

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.

Code:

$ ./bitcoin-qt -signet
Error: basic block filter index best block of the index goes beyond pruned data. Please disable the index or reindex (which will download the whole blockchain again)
Error: Failed to start indexes, shutting down..

And when i reopen Bitcoin Qt (Signet) again without prune/filter, it currently redownload whole blockchain.

And how are BIP158 filters different from Bloom filters (peerbloomfilters setting in bitcoin.conf)?

peerbloomfilters refer to BIP 37 which deemed to have broken privacy model.

[NotATether]

Code:

$ ./bitcoin-qt -signet
Error: basic block filter index best block of the index goes beyond pruned data. Please disable the index or reindex (which will download the whole blockchain again)
Error: Failed to start indexes, shutting down..

And when i reopen Bitcoin Qt (Signet) again without prune/filter, it currently redownload whole blockchain.

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

[ranochigo]

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.

[NotATether]

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.

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?

[ranochigo]

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?

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.