Settings up your node for filtering Runes

Pros and cons when setting filters in your node against Runes

In this article we are going to see how to filter Rune, the protocol by Casey Rodarmor which come in production on Bitcoin halving day 2024.

Filtering the Runes

In the last days we have seen the introduction of Rune protocol, starting from the Halving day in 2024 (block height 840000). The introduction of such a protocol, caused an important increase of miner fees in the next hours after the halving itself. Later miner fees decreased but are still at high values.

There is a lot of Bitcoiners who consider Runes as spam affecting the Bitcoin Network and therefore they are trying to find a way to fight this phenomenon. Let’s now see what settings we can play in our node for this purpose and what are the collateral effects we may experience.

You can change the configuration of your Bitcoin node in various ways in order to fight Rune spam, here you go:

Set datacarriersize=0

The first option is setting datacarriersize=0 as suggested by Bitcoin dev Luke Dashjr in this post on twitter

https://x.com/LukeDashjr/status/1781749769431650700

So if you set datacarriersize=0 what you do is you remove all the OP_RETURN from the outputs, so you clearly remove the Runes, which is this new spam attack, but you also remove other features like the OpenTimestamps, RGB in the current version used for example by Federico Tenga, which uses OP_RETURN and you remove BIP 47 so Paynym by Samourai ( https://blog.samourai.is/how-bip47-works/ ) , etc. So basically all OP_RETURN are cut off and therefore you have to evaluate if this is a problem for you.

Even knots allowed 40 bytes of OP_RETURN because the idea was that this was a good place for generic data in 40 bytes. In 40 bytes there is infact enough space for a hash and an identifier; then core extended it 80 bytes, Knots kept it at 40.

If you put datacarrier=0 it takes away all the OP_RETURN so you keep seeing the mempool, you keep getting to the transactions, but you take away the Runes and you also take away all the mentioned stuff above.

Set blocksonly=1

Instead the alternative is blocksonly=1, in which case you really have no longer a local mempool. People is asking: what about the miner fees estimation from my node if I set this configuration?

In this case, please note that the fee estimation does not depend on the mempool only, it also depends on the historical blocks. If you pay attention to past blocks (already mined) you will notice that you can get miner fees estimation from there. Only in case of immediate spikes this estimation can be wrong, but just for the next block. So we can say that our fee estimation without mempool can be wrong, in the moment of a spike until the next block and that's it.

You also have to consider what happens if your wallet is connected to your own node and you set blocksonly=1. In this case if you try to broadcast a transaction, the node will not accept it and it will refuse it. But when it will be mined ( as propagated by other nodes) you will see it when included within a block.

So please think about your specific case, your node and your ethical thinking about this kind of activity on the Bitcoin timechain.