In recent debates about changes to and differences between Bitcoin clients, two fundamentally different types of Bitcoin rules are often mixed up together in arguments or simply confused with each other. Understanding what kind of rules are being enforced by a Bitcoin node – and to what end – is crucial for understanding changes to the Bitcoin protocol, or discussions about them. Let’s take a closer look at the difference between consensus rules and mempool policies.

Consensus rules

If you think about it, Bitcoin is simply a set of rules, independently enforced by thousands of nodes and miners around the world. Some of these rules, arguably the most important ones, determine whether a block is valid. They are essential for achieving consensus in the network, since participants have to agree on them in order to agree on which chain of blocks is “the real Bitcoin blockchain”. Without consensus on these rules, there would effectively be no Bitcoin network – which is why we call them consensus rules.

Many of the consensus rules are quite obvious, and you might naturally come up with them when thinking about the validity of a Bitcoin block. For example, transactions cannot spend bitcoin twice, miners cannot create more bitcoin in a new block than what is currently allowed and the block size cannot be larger than the maximum limit. 

“Your node, your rules” is a common saying among people running their own Bitcoin node. While the saying is true at its core, it’s not really that easy to “just make your own rules” on an individual level. If you, for example, program your node to reduce the maximum block size from 4 MB to 0.1 MB, your node would simply start rejecting new blocks – and that’s it. You would simply get out of sync with the rest of the network, effectively locking yourself out without anyone noticing. 

A change to the consensus rules happens quite rarely in Bitcoin and always results in a hard or soft fork. Popular examples of Bitcoin soft forks include the Segwit update in 2017, and the Taproot update in 2021. An example for a rather controversial hard fork is the network split and subsequent creation of Bitcoin Cash in 2017. In all of these cases, the consensus rule change was a more or less coordinated effort among lots of users, miners and developers.

Mempool policies

Note that not all rules that are talked about in Bitcoin are relevant for consensus. Some “rules” are actually just simple configuration settings for your own node, e.g. to manage its resources more efficiently or help broadcast certain transactions more effectively. Because these configurations influence which transactions are kept locally in the node’s mempool and relayed to other nodes in the network, we call them mempool policies. 

When you create a new transaction, your wallet sends it to the Bitcoin node it’s connected to, which in turn relays it to other nodes, and so on, flood-propagating it across the entire network. The mempool policies of nodes in the network therefore directly influence how effectively a transaction spreads through the network – at least to a certain extent. 

Eventually, most transactions reach most nodes, even when some nodes don’t relay them.

Some examples for mempool policies are:

  • The minimum fee rate required for a transaction to be relayed.
  • The maximum amount of data in OP_RETURN outputs for a transaction to be relayed.
  • The maximum mempool size before low-paying transactions are dropped.
  • Whether to relay non-standard transactions or not.
  • … and more

The configuration of these policies is fully up to the node operator and they can be changed at whim, as they don’t influence the transaction’s validity anyway. Even if your node drops a certain transaction from its mempool, that very same transaction might appear in the next Bitcoin block, and your node will still mark it as valid, because it does not violate the consensus rules.

One beats 99,9%

One crucial aspect about policies is how they – by definition – cannot be enforced on a protocol level, otherwise they would be considered consensus rules. This is the reason why it’s very hard (or in some cases even impossible) to effectively influence which transactions end up being confirmed in a new Bitcoin block through mempool policies alone.

Let’s use an example to illustrate this: You might have heard of the “minimum fee rate” in the Bitcoin network being 1 sat/vB. It’s a very common fee rate to use if the network is not as crowded with transactions and most wallets will not even allow you to set a fee rate below that value, for good reason.

However, the 1 sat/vB fee rate is not a hard minimum, despite almost all nodes simultaneously enforcing this policy on their local mempools. It may be hard to broadcast transactions below 1 sat/vB the usual way, but from the perspective of the consensus rules, there is nothing wrong with transactions paying zero fees at all. You can even find such transactions regularly, mainly Coinbase transactions or any other transactions miners want to prioritize over others (since there would be no point of paying a fee to themselves). The 1 sat/vB is nothing more than a default configuration value which has become an established standard – one you can avoid, if you really want to.

Recent blocks include many transactions with fee rates below the standard 1 sat/vB.

If you followed the debate about raising the data limit for OP_RETURN outputs, you can apply this principle in a very similar way, since the configuration option limiting the amount of arbitrary data allowed in these transactions is also just a mempool policy. Even if a large majority of nodes stop relaying transactions with OP_RETURN outputs entirely, a few outliers who still do would be enough for the transaction to be included in a block – provided it pays a large enough fee. In theory, all it takes is a single miner to directly circumvent the policies set by 99,9% of the rest of the network.

Some nodes are stronger than others

Not all nodes are the same – technically speaking. While one node might run on a small Raspberry Pi with limited memory, computing power, another one might be hosted at a powerful cloud provider, with hundreds of gigabytes of memory and powerful CPU. Both have their place in the Bitcoin network, but they also have vastly different levels of resources at their disposal.

This is where mempool policies can come into play quite effectively: For example, the more powerful node can raise its maximum mempool size to several gigabytes, enabling older and lower paying transactions to not be forgotten that quickly. On the other hand, the Raspberry Pi might want to set the bar lower, only allowing a few hundred megabytes of transactions to be kept in its mempool. This allows the node to keep track of incoming, higher paying transactions, which are more likely to be included in the next block anyway, allowing it to stay up to date efficiently, without running out of memory. 

Limiting spam

This section is not about limiting arbitrary data on the Bitcoin blockchain, but instead another helpful effect mempool policies can have. Imagine a node enforcing no minimum fee rate and no maximum mempool size: An attacker could now broadcast “spam transactions” with no fee (and thus less financial costs) to this node, keeping it busy with nonsensical transaction validation, until it runs out of memory and crashes. On the other hand, a node with a minimum fee rate policy would simply reject spam transactions with zero fees. In addition to that, it would even raise the fee rate dynamically, once the mempool reaches its limit set by the maximum mempool size policy. In short: Mempool policies can act as practical sanity checks to keep a node within a sensible and safe operating window.

Conclusion

When mempool policies are tuned to a node’s technical limitations or the operator’s personal preferences, they can help to make the Bitcoin network more efficient at exchanging information between peers, all while protecting nodes from abusive usage patterns. 

However, it’s crucial to keep in mind that mempool policies cannot be turned into consensus rules by simply running them on your own node and encouraging others to do the same. Because they do not determine a Bitcoin block’s validity, their use case is limited to optimizing how your node interacts with the network and manages traffic, not defining what Bitcoin is.

Don’t own a BitBox yet?

Keeping your crypto secure doesn't have to be hard. The BitBox hardware wallets store the private keys for your cryptocurrencies offline. So you can manage your coins safely.

Both the BitBox02 Nova and the BitBox02 also come in a Bitcoin-only edition, featuring a radically focused firmware: less code means less attack surface, which further improves your security when only storing bitcoin.

Buy the BitBox02 Nova or grab a BitBox02 in our shop!

Shift Crypto is a privately-held company based in Zurich, Switzerland. Our team of Bitcoin contributors, crypto experts, and security engineers builds products that enable customers to enjoy a stress-free journey from novice to mastery level of cryptocurrency management. The BitBox02, our second generation hardware wallet, lets users store, protect, and transact Bitcoin and other cryptocurrencies with ease — along with its software companion, the BitBoxApp!