Bitcoin Mempools: What are they and why do we need them?

My previous experience article on the mempoolIn this article, I presented a conceptual framework that could be used to understand the functionality of the Bitcoin mempool and the different ways it is utilized by the various types of Bitcoin users. In this article, I’ll be examining the differences between a relay policy and a consensus rule. Also, why Bitcoin nodes default to not relaying certain bitcoin transactions that are valid by consensus. 

Nodes will receive and download these transactions when they get the block. This is regardless of whether or not the peer-topeer network refuses to relay some types of valid consensus transactions. There is no way to prevent this, short of making consensus rules invalidate those transactions. 

Different types of filters are used for various reasons. Three types of filters can be used: those to protect the nodes and the network from Denial of Service, those for upgrading hooks in future softforks as well as those designed to gently discourage Bitcoiners who might dislike certain things but which do not pose a serious threat. 

The Denial of Services Vectors

Bitcoin Computer programs are nodes. The technical restrictions of any program running on a computer apply to nodes. This includes limitations in storage, processor power, memory etc. The blocksize limitation was created to keep verification costs for standard devices reasonable. 

The filters in this class are designed to make sure that, even with the limit on blockspaces, individual transactions which can use up too many resources of a node do not. 

Simplest example is the minimal feerate required for a particular transaction to spread, or the Replace-By-Fee rules that dictate when another version of the transaction may replace the old one. Only when the transaction pays more than its previous version. As soon as you accept a payment, the transaction is yours. If you do not doublespend, anyone who receives that transaction will be able to mine and collect the fee. You can only avoid paying this cost by spending the UTXO first in a transaction that also charges a fee. 

DoS protection is the reason. Users could create unlimited variations of one transaction, and then send them to all nodes in the network. Memory and bandwidth would be consumed. This would continue indefinitely. Users would be unable to pay for bandwidth or nodes in the network could crash. 

Validating transactions that have been filtered out by the relay policy can be expensive. You can create transactions which are extremely expensive to validate. A Bitcoin node using consumer-grade hardware will need over an hour just to verify some blocks. It is possible to do this by using large scripts designed to generate the most signature checks and then stuffing an entire block with only these transactions. 

These script structures and testing times have been done before, however the code structure has never been revealed. This is for obvious reasons. The transactions could literally slow down the network. 

Dust limit would be a final example of DoS. The dust limit prevents transactions that create UTXOs below this value from being relayed, because it would cost more to spend the UTXO than its satoshi worth. The UTXO set will have to hold these outputs indefinitely because it is uneconomical. It could lead to a bloated UTXO collection that would make block validation computationally more intensive. 

Future Softforks

Softforks have allowed all major updates to the Bitcoin protocol to take place. This upgrade method allows for new script functionality in the protocol to be added while still being accepted by nodes that are not upgraded.

Bitcoin includes a script that allows for this. “undefined” Opcodes are automatically valid, as there is no current verification rule for their use. Upgraded nodes, which will enforce the rules when people upgrade, will use the rules to apply against the opcodes, while older nodes simply accept their usage. If miners don’t mine transactions which violate the rules prior to the upgrade of the node network, then everyone will stay on the same Blockchain and all the backward compatibility is maintained. 

The relay policy is used to filter transactions using undefined opcodes. It is important to maintain the ability of Bitcoin’s protocol to be upgraded. 

If users made UTXOs with undefined opcodes in conjunction with defined ones, so they couldn’t be spent by anyone, if this undefined opcode was given verification rules during a softfork, that UTXO became unspendable. If the script structure is not able to comply with the new rules of verification, it will be unspendable. 

If these UTXOs are allowed to propagate, they could be used to make any future softfork into a dilemma between upgrading the software or making some users’ coins inaccessible. 

Discouragement

Some transactions, while not causing any harm to the nodes in the network (i.e. A large group of users on the network find crashing of nodes and using excess memory or resources as undesirable. 

These transactions could include those that use large OP_RETURN or Inscriptions using the Witness field to add arbitrary data to the Blockchain. The Bitcoin network does not encourage these types of transactions because it isn’t viewed as their primary application. 

There are differences between everything

There are clearly distinct differences between the different relay filter classes. Relay filters are not created for the exact same reasons, and not every filter has the same incentive for miners. Each relay filter has a purpose. It protects your node (or the blockchain) from things which are harmful, but also unwanted. 

Filters aren’t all the same and they filter things differently. From problematic transactions (that should be addressed at the level of consensus) to simply discouraging transactions that people find unwanted. 

The difference is important. It’s important to understand the difference between these two things. It would affect their investment.