So I’ve been playing around with Bitcoin version 12, currently in development and close to being tagged for an official release. While I was aware of maxmempool and mempoolminfee I’m just beginning to grasp the economic significance and possible technical hurdles during and after it’s deployment.

The mempool is where transactions that have been broadcast to the network, but not yet included in a block hang out. These are known as “unconfirmed transactions”. Mempool is kind of like a transaction verification waiting room, until transactions are confirmed by being included in a block they hang out in the waiting room and can not be trusted.

On the current network (client versions below 12) pretty much all valid transactions are included in a nodes mempool until one of two possible outcomes happens; the systems available memory fills up and it likely crashes, or a block is found reducing the size of the mempool. The size of the mempool, or the waiting room, is not defined by bitcoin but by the system it is being run on. This is obviously not ideal, and to fix the problem a mempool limit is being introduced in version 12 via maxmempool.

Prior to version 12 nodes have control of what transactions they relay (share with other folks on the network) based on fee with minrelaytxfee and how how large of a block they will create with blockmaxsize (up to the hard limit of 1MB), but basically nodes will see and store ~all~ new transactions in the mempool; up to and including filling up the nodes available memory and most likely crashing it.

Currently the fee market comes into play when mining pools select what transactions from the mempool to include in a block. While miners can cherry pick, for the most part transactions are sorted by fee per kilobyte, and the transactions with the highest fees are selected from the mempool and included in a block. This is the current fee market.

The fee market behavior will significantly change with the introduction of maxmempool, here’s how:

So the way the new maxmempool setting works is by limiting the size of the mempool (our transaction waiting room) to a fixed amount. The current default is 300MB, and it is user configurable. The expected behavior is that users on smaller systems would reduce it to fit their hardware limitations, while users running on server grade hardware would increase it to accommodate more unconfirmed transactions. For the sake of this article lets assume most folks stick with the default 300MB.

I’ve been running a version 12 node on the main network to observe this new features behavior for about a week now, and the 300MB default limit is often reached. I began to wonder what happens with new transactions when my node is at it’s limit. With some research (and outside help) I was able to figure it out.

Basically when your maxmempool size is reached your node will begin to evaluate whether or not to include a new transaction in it’s mempool based on it’s fee as compared to the transaction with the current lowest fee already in your mempool.

Your node will then (when maxmempool is reached) begin dynamically adjusting mempoolminfee to allow only new transactions with a higher fee into the mempool. When a new higher fee transaction is accepted, the old transaction with a lower fee that was in the mempool is kicked out, essentially moving it from the waiting room to purgatory.

Fee lower then current mempool lowest fee: If the new transactions fee is not greater than the fee paid by the transaction with the lowest fee in your mempool it will be ignored (off to purgatory land).

Fee higher then current mempool lowest fee: If the new transaction has a higher fee than the fee paid by the transaction with the lowest fee currently in the mempool it will drop the lower fee transaction and replace it with the new one that includes a higher fee (higher fee gets in the waiting room, lower fee that was previously in mempool off to purgatory).

My concerns for when this occurs are the following:

It is difficult, if not impossible, for an end user or their wallet software to determine whether or not their transaction is currently in a mining pools mempool or meets a pools current mempoolminfee. No existing wallet implementations I am aware of are prepared to handle this. This may create an enormous amount of transactions that never even see the mempool’s waiting room, and end up stuck in purgatory until the user takes the highly technical action of rebroadcasting it with a higher fee, likely from a different wallet implementation.

This in essence creates a secondary fee market.

The first that exists today is the fee to be included in a block in a reasonable amount of time. This secondary market will emerge as the fee to be included in the current mempool at all.

Note: I do see limiting the mempool size as vital, and I do not currently have a better solution, this was simply a realization of the impact of maxmempool and mempoolminfee that I had not previously understood.