In a previous article on Mempool, I created a simple conceptual framework to infer the basic features of Mempool and how it was used by different types of users of the Bitcoin network. In this article, we will consider the differences between relay policies and consensus rules and why Bitcoin nodes do not relay some kind of Bitcoin transactions despite the consensus enabled by default.
First and foremost, regardless of peer-to-peer networks that refuse to relay a particular type of consensus-enabled transactions, if those transactions are selected to be found in miners’ memory and included in a block, they will be received and downloaded by the node when they receive the block. This consensus change cannot be prevented in order to disable a class of consensus based on consensus rules.
There are different types of filters for a variety of reasons. Three common types of filters are those that protect nodes (and therefore networks) from denial of service (DOS), those that protect future soft fork upgrade hooks, and those that do not like bitcoiners but otherwise do not cause serious harm to individual nodes or networks.
Refusal of service vectors
A Bitcoin node is a computer program running on a computer. This means that there are all technical constraints of programming running on a computer, including storage, memory, processing power, and more. This is the root of why block size constraints were introduced and maintained, creating global constraints that keep validation costs reasonably high on regular devices.
Filters of this class are specially designed whether you limit individual transactions that can be created with block space, or individual transactions that can consume the resources of a node.
The simplest example of such a filter is the minimal enrichment required for a transaction to propagate, and is directed by a Rule (RBF) rule that only indicates if different versions of the same transaction can replace the previous version, i.e. pay a higher fee than the last version. Once you sign the transaction for a fee, you’re on the hook. Unless you double it, the miners who have acquired that transaction can mine it and collect its fees. There’s no way to avoid paying that fee other than using UTXO on another transaction first (this also requires a fee).
The reason for this is DOS protection. Without putting themselves on the hook with a fee that cannot escape payment, users can simply create infinite variations of a single transaction, spamming the memory of every node on the network, and eating bandwidth and memory in the process. There is nothing to stop them from doing this forever. Nodes on the network crash completely, or the higher the bandwidth costs are, the higher the user can’t afford them.
Another example of a transaction filtered by a relay policy is expensive to validate transactions. It is possible to create very expensive transactions to verify. You can create several blocks to run and check Bitcoin nodes running on regular consumer hardware over an hour. This is done by creating large custom scripts designed to create the largest amount of signature checks and stuffing blocks other than these transactions.
Such script structures have been constructed previously, and validation times have been tested on a variety of machines, but the exact structure of these scripts has not been exposed by such developers for obvious reasons. These are transactions that can literally stall the entire network.
The final example of DOS protection is dust restrictions. Transactions that create UTXOS with satxos values below the dust limit will not be relayed as the cost of using that UTXO is higher than the output Satoshi value. This means that the UTXO set needs to store these outputs permanently, as it is uneconomical and unlikely to be spent. This could create a bloating UTXO set that makes block verification more computationally intensive.
Future soft forks
All major upgrades to the Bitcoin protocol were made at SoftForks. This is an upgrade mechanism that allows new scripting functionality to be added to the protocol to accept that the Un-Upgraded node is still enabled.
This is possible because the bitcoin script contains “undefined” opcodes. This means that no validation rules are currently defined, so their use is automatically considered valid. When people upgrade a node to enforce new rules, the upgraded rules apply new rules to that opcode, and the old rules simply accept their use. As long as miners do not mining mining transactions that violate the new rules before all node networks are upgraded, everyone will remain on the same blockchain, everything is in the opposite direction.
Transactions using these undefined opcodes are filtered by relay policy. This will be done to maintain the upgradability of the Bitcoin protocol in the future.
If a user creates UTXOS using such an undefined opcode, it combines with the defined opcode to prevent anyone from spending if the user is given a validation rule with a softfork that says utxo is dapendable with softfork. The script structure cannot meet new validation rules that are applied during softforks.
By propagating and being able to see these, we can use UTXOS to turn future potential soft fork upgrades into a philosophical dilemma of not being able to transfer coins for some users.
Disappointment
There are several types of transactions that do not actually harm nodes on the network, but use node crashes, excessive memory or resources, and the majority of network users are undesirable or opposed to the primary purpose of Bitcoin.
Examples of such transactions are those that use large op_return outputs, or inscriptions using witness fields, to write any information on the blockchain. These are disappointing because they are not considered major use cases for the Bitcoin network.
Not everything is the same
These different classes of filters in relay policies are very distinctly different. Not all relay filters exist for the same reason, and not all of them have the same incentives that miners mine (or not mine). Each of them exists for a specific purpose to protect a node or blockchain from a variety of types that are justified infringing damage or simply undesirable.
Not all filters are the same, and the differences between what they filter are big. It simply discourages harmless transactions that people find undesirable from problematic transactions that can cause the network to crash (which must be fixed at a consensus level).
It is important to make the difference between these things. For example, miners may simply mine unwanted transactions if the user pays for it, but reasonable miners will not mine blocks filled with transactions that crash the entire network. That would undermine their investment.
This post Bitcoin Mempool: Why We Have Filters first appeared in Bitcoin Magazine and is written by Shinobi.
