How would I set a more permissive mempool policy?

Question

The mempool will reject some transactions that are valid per the consensus rules.

I would like to configure my mempool to be liberal in what it will accept, provided fees are paid. Are there any recommendations for node runners wishing to do this? Is there any risk my node might get dropped by it's peers if it does relay these transactions?

My motivation is to accept transactions that users would otherwise go directly to mining pools to have mined.

Answer 1

I had similar motivations when I began running my full node some time ago, and am happy to share my experience and provide suggestions on how to set a more flexible mempool policy.

To do so, you need to modify the settings specified in your bitcoin.conf file.

Following parameters influence how your node accepts and relays transactions and have a direct impact on the mempool policy.

1. minrelaytxfee: This sets the minimum transaction fee rate in BTC/kilobyte that your node is willing to relay. Default value is 0.00001 and it instructs your node to accept transactions with at least 1 satoshi per byte. You can set this to a lower value to accept transactions with lower fees. Based on my experience, reducing the value of this parameter does not significantly improve the situation. Nowadays there are no miners mining transactions that pay less than the default minrelaytxfee. Hence, I suggest that you retain the default value and avoid changing it to a higher one.

minrelaytxfee=0.00001 

2. maxmempool: This sets the maximum size of the mempool in megabytes. You can increase this value to allow your node to store more transactions in the mempool. Default mempool size is 300 MB. I am running my node with a mempool size set to 2 GB. Around one month ago, the overall size of the mempool was nearly 1 GB. At that time the nodes with default mempool size purged transactions below 5 sat/vB - which means such transactions were not propagated among peer nodes or stored in their mempool. During that time, my own node was still accepting and relaying transactions at a minimum fee rate of 1 sat/vB. In my opinion, this parameter has the most profound impact on achieving the desired mempool policy.

maxmempool=1000

3. mempoolexpiry: This sets the expiration time for transactions in the mempool in hours. You can increase this value to keep transactions in the mempool for a longer time. Default value is 336 (2 weeks). I previously ran my node with mempoolexpiry=672 but later switched back to the default value. I guess it is Okay if transactions get removed from mempool after two weeks, but you are open to keep old transactions in mempool longer this way. As far as I know, nodes re-transmit old transactions at regular intervals.

mempoolexpiry=672

Adjust these parameters according to your desired mempool policy and save the changes. Then, restart your node for the new settings to take effect.

In the early Bitcoin days, from version 0.3 until 0.15, there was also a parameter limitfreerelay: This was used to set the rate limit for free transactions in thousands of bytes per minute. You could increase this value to relay more free transactions. This is no longer possible.

The risks involved in running a more permissive mempool are: If your node relays transactions that other nodes consider spam, they may stop relaying transactions to your node or even ban your node. This can lead to reduced connectivity and a less reliable mempool.

To mitigate this risk, you can try to maintain connections with nodes that share similar mempool policies or operate private peering connections with like-minded node operators.

It's essential to strike a balance between being permissive and maintaining good relationships with other nodes on the network. If you're too liberal in accepting transactions, you might end up with a less useful mempool and reduced connectivity.

I would also appreciate any information regarding other options that can establish a more liberal mempool policy. Perhaps, other node operators can provide additional insights on this topic in the comments.