The term “mempool” is a contraction of the English words “memory” and “pool”, which can be translated into French as “memory” and “basin”. Thus, a mempool is a temporary space containing Bitcoin transactions waiting to be integrated into a block. This space is maintained by each node in the network.
In this article, we look at the technical nature of mempools on Bitcoin, as well as their role in how the protocol works.
What is a Bitcoin mempool?
When you want to make a transaction on Bitcoin, the first step is to sign it using the private keys contained in a wallet. Once signed, the transaction is transmitted to a network node that ensures compliance with established rules. If the transaction meets all the validity criteria, this node then propagates it to other nodes in the network that it is connected to. This streaming process continues, and quickly, the transaction should have reached most nodes on the Bitcoin network.
If the transaction has enough fees, it will be selected by a miner to integrate it into a block. As soon as a miner succeeds in generating a valid block containing the transaction, it is confirmed by the distribution of the new block on the network.
The “mempool” refers to the temporary storage space hosting transactions validated by the nodes, but not yet included in a block. As long as a transaction awaits confirmation, it resides in the node mempools.
Although the term “the mempool” is often used as if it were something unique, it would be more accurate to speak in the plural of “mempools.” Indeed, each node in the Bitcoin network manages its own mempool, and there may be differences between the mempools of each node.
How are mempools managed on Bitcoin?
A node's mempool is therefore constantly evolving according to the new information it receives. When new transactions are issued by users, the node saves them in its mempool. Conversely, when a miner finds a block to add to the blockchain, the node looks at the transactions confirmed in that block and removes them from its mempool.
Since mempools represent storage space for transactions awaiting confirmation, they are necessarily limited in size. Indeed, each node is free to define a maximum limit for its personal mempool.
By default, on Bitcoin Core (the majority implementation of the Bitcoin protocol), the maximum limit is set at 300MB. This means that a node will accept pending transactions until it reaches this ceiling. Beyond that, he will begin a process of prioritization based on costs. Transactions offering the lowest fees may then be excluded from the node's mempool. Concretely, this results in the deletion of these transactions from its memory.
Each node can change the size of its mempool by adjusting the parameter MaxMempool in the configuration file bitcoin.conf. However, most nodes keep the default limit of 300MB. There is therefore a certain homogeneity in terms of the capacity of mempools on Bitcoin.
This uniformity has a consequence: when a transaction is rejected from 300MB mempools, it is in fact removed from the Bitcoin network, as if it were cancelled. To prevent this scenario, an indicator called the” Purge rate ” informs us of the minimum transaction fees necessary to avoid being forgotten by the node mempools.
For example, if the cumulative number of pending transactions offering more than 2 SATs/vb reaches 300 MB, the purge rate will be set at 2 SATs/vb. Transactions offering fees below this threshold will then be excluded from mempools. Naturally, this rate fluctuates according to the demand for space in the blocks and the supply generated by the mining activity.
As explained in the previous part, for a node to agree to add a new unconfirmed transaction to its mempool, the mempool must comply with certain rules. These standards are divided into two types:
The consensus rules;
And the standardization rules, also known as the “Mempool rules.”
Consensus rules are a bit like the fundamental laws of the Bitcoin protocol. They ensure the consistency and integrity of the entire system by defining the criteria by which transactions and blocks are validated. A transaction that violates consensus rules cannot be included in a valid block. For example, a transaction with an invalid signature could not be mined on the blockchain. These consensus rules are the same for all Bitcoin users and are applied collectively.
Standardization rules, on the other hand, are determined by each Bitcoin node independently. They define additional criteria for the structure of unconfirmed transactions that the node is willing to accept into its mempool and distribute to its peers. These rules are configured and executed locally by each node. They may vary from node to node and only apply to unconfirmed transactions. Thus, a node will only accept a transaction that it deems non-standard if it is already included in a valid block.
While these rules may differ from node to node, most maintain the default settings established in Bitcoin Core. Since this implementation represents more than 98% of the Bitcoin network, there is in fact a homogeneity of standardization rules across the nodes.
A transaction that, although in accordance with consensus rules, does not respect these standardization rules, will therefore have difficulty spreading on the network. However, it can be included in a valid block if it ever reaches a minor. In practice, these transactions, which are described as non-standard, are generally transmitted directly to a miner via channels external to the Bitcoin peer-to-peer network. This is often the only way to confirm this type of transaction.
To illustrate the distinction between these two types of rules, let's take transaction fees as an example. From a consensus perspective, there are no fee requirements. A transaction may therefore have no fees and may nevertheless be integrated into a block that complies with consensus rules. The block will be accepted by the node network. For example, here is a mined transaction with no fees: fd456524104a6674693c2994693c29946543f8a0befccce5a352bda55ec8559fc630f5f3
On the other hand, by default, the standardization rules require transactions to allocate at least 1 sat/VB in fees. So, if a node receives an unconfirmed transaction with zero fees, it will refuse to integrate it into its mempool and will not broadcast it to the other nodes.
A transaction that is free of fees is therefore both valid under consensus rules and non-standard under mempool rules, because Bitcoin Core's default policy for the parameter MinRelaytxFee Is of 0.00001 (in BTC/kb).
The mempool represents a temporary reservoir within the nodes for Bitcoin transactions awaiting confirmation. Each network node has its own mempool.
The capacity of mempools is restricted, generally to 300MB, in accordance with the standard Bitcoin Core configuration. Thus, they can only contain a limited volume of transactions, prioritized according to their fee rates. During periods of congestion, a “purge rate” is established to indicate the minimum fee required to avoid excluding a transaction from mempools.
To be integrated into a block, Bitcoin transactions must respect consensus rules. A second layer of more restrictive rules, called standardization or mempool rules, is applied individually by each node. Transactions that do not meet these additional rules are not added to the node's mempool and, therefore, are not propagated across the network.
.png)
.png)
.png)
.png)
.png)
