The Bitcoin blockchain rewards it's participants to keep the electricity on and the miners running. It is a cornerstone of the industry, and the Mempool is the least understood part of it. This article explains the Mempool.
The miners are also permitted to choose the transactions submitting the highest fees to process. This is common sense - any miner would prefer a higher fee if given an option - it's the "icing on the cake": 1 BTC + fees.
"Average Bitcoin transactions per block represent how many transactions are included in each 2 MB block, on average, in a given day. Assuming an average transaction occupies 570 bytes of data, then a block can contain approximately 3,500 transactions, given the 2 MB limit."
There are always more transactions waiting to be processed than the Blockchain can handle. These transactions "on hold" are put into a special list called a "mempool".
A Bitcoin Node is a software program, running on a server, that shares and confirms Bitcoin transactions (as well as wallets).
There are around 10,000 Bitcoin Nodes currently operating.
A mempool is maintained on each Bitcoin Node.
The Bitcoin Node that accepted your transaction, adds the transaction to it's own mempool.
That Bitcoin Node then shares that mempool with the rest of the Bitcoin network.
An unconfirmed transaction is held in a mempool somewhere amongst the many collective mempools known to the Bitcoin network.
When referring to "the Mempool", this article refers to the collective Bitcoin NETWORK mempools (not just a single mempool on a single Bitcoin node). |
The Bitcoin network processes a transaction from the Mempool on a specific Bitcoin Node when the fee "fits" into the block. A miner would rather have 10 satoshis than nothing, so it fits the lower-fees into it's block when they have the space available.
Fees that are below a certain minimum may take DAYS (or longer) before they are accepted into a block!
Once the transaction is selected and accepted from the Mempool, it is removed from the Mempool and becomes "confirmed".
The industry standard is that the transaction is “authentic” (immutable) after 3 confirmations.
These websites (there are many) show the current Mempool status and the fees that are bidding for the quickest processing: |
BE CAREFUL!! |
The customer may have intentionally sent it with a low fee, hoping to pressure you into releasing the cash before the transaction has confirmed.
The customer has a number of tools available to void or reroute that transaction BEFORE IT CONFIRMS - leaving you scammed. Don't become a victim.
It could be an accident - completely unintentional - or it could be an attempt to defraud you. You'll have to use your own judgement.
The bottom line: the customer sent you BTC with a low fee. That's their fault; don't bend to their demands.
Hypothetical situation:
A customer creates a server, and installs a Bitcoin Node. Anyone can do this.
The customer sends BTC to the Bitcoin Node that he controls to begin the scam.
The customer initiates a SELL at your BATM3 with an unreasonably low fee sent by the Bitcoin Node that is under his control. It shows as "unconfirmed".
After a day or two, it still hasn't cleared (of course: too low a fee).
He complains to you, "WHY IS THIS TAKING SO LONG?!!"
You capitulate after being manipulated; he walks away with the cash in his hand.
That same “customer” then shuts down his Bitcoin Node and the unconfirmed transaction is automatically voided by doing so. You will never receive the BTC. He scammed you.
A common question regarding SELL settings in CAS is: “how to properly set the minimum and maximum mining fees?”
This is a complicated question. CAS uses (by default) an X rolling method of calculation. It looks at the last X transactions, averages them out, and forwards the SELL transaction using that average. This is where it gets complicated.
If the fee is rapidly moving higher, the transaction may get stuck in the mempool. This may happen on occasion when using the default settings. It’s inevitable. There are 2 approaches:
Wait it out. The transaction will eventually clear and your target wallet will be credited. Smaller transactions can usually wait in this situation.
Manually increase the fee. Sometimes this is appropriate, e.g. a large transaction that impairs your ability to do business. There are 2 types:
RBF (Replace By Fee) resubmits the same transaction to the network with a higher fee.
CPFP (Child Pays For Parent) creates a child transaction that forces miners to also include the parent in the block.
So, how do you avoid this issue to begin with?
You can set the SELL Minimum Mining Fee Per Byte and Maximum Mining Fee Per Byte settings. When you set these numbers, you ensure that your transactions are processed within a defined fee range. The “X rolling” fee calculation is still used, but it will never be less (or more) than the range you set here.
Minimum Mining Fee Per Byte ensures that the transaction is never submitted to the network with a trivial fee. The vast majority of “stuck” transactions involve fees of 1 sat/byte (or less).
Set too high: your profitability suffers.
Set to zero (default) or too low, and the “stuck” transaction will eventually happen.
Here’s a current graph of the mempool fees from https://jochen-hoenicke.de/queue/#BTC,30d,weight:
The bottom layer is “0-1” sat/byte. In the past week, most every transaction fell into this fee range, and many cleared during the week. Transactions over 10 sat/byte cleared within an hour (or less).
Between Sep 18 - Sep 24, the only transactions that cleared had fees over 17 sat/byte.
In this case, a minimum fee of 10 sat/byte may have been vulnerable to being “stuck”.
This vulnerability was only a problem if the CAS algorithm erroneously calculated a fee based on the last X transactions' fees not exceeding 17 sat/byte. In other words, the conditions would have had to be “perfect” for the CAS algorithm to fail to post a proper fee. This rarely happens, but it isn’t impossible.
Here’s a current graph of the mempool fees from the past year:
In this chart, a minimum fee of 140 sat/byte would have been vulnerable at some point.
And 6+ years:
In this chart, a minimum fee of 400 sat/byte would have been vulnerable at some point.
The takeaway is: there is no “perfect” minimum. You will always be vulnerable as long as you are profitable. Paying 400x the average mining fees to avoid any delay is unreasonable (and expensive).
The best advice? Set it to 2 sat/byte (or slightly higher). This will mitigate the problem for most transactions, while still retaining some level of profitability.
In the chart above, you can see that a mining fee of 400+ sat/byte was offered for some transactions.
At that time period, Bitcoin was around $4k, so a single fee could have been over $10. In some cases, the fees exceeded $20 per transaction - and Operators endured losses. You’re not in business to lose money.
Setting the Maximum Mining Fee mitigates your exposure to such problems. During a period of extreme fees, ALL your SELL transactions will get “stuck” - but you won’t suffer accidental loss.
Set the Maximum Mining Fee to a comfortable number that ensures your transaction consistently clear yet remain profitable.