What is a mempool and how to use it
The mempool as a concept
There are plenty of good mempool sites but for the purpose of this, I’ll be looking at mempool.space. I’ll also go over what you see on this dashboard, and how to use this information to save money, increase your privacy, and understand Bitcoin better.
What is a mempool?
The mempool is a queue that contains pending transactions. Miners then process these transactions based on their own economic incentives when they create a block (the higher the fee, the faster that transaction will be included in a block because the miner gets paid more by choosing that transaction over a transaction that paid a lower fee).
How to understand this dashboard
- The number of pending blocks in the mempool. Each block averages 10 minutes so you can either pay the current market fees to have your transaction included sooner or wait the number of blocks times 10 minutes to make a cheap transaction when the mempool is empty
2. The estimated fee in the next few blocks. It pays off to be patient as
3. The estimated fee of the next block
4. The last block mined or head of the chain
5. The estimated fee based on your priority needs
6. The difficulty adjustment for this period
7. A general overview of that mempool. I said “that” mempool instead of “the” mempool because there is no one mempool. Anyone who runs a node has their own mempool and depending upon your peers, your mempools will be different in specifics but the general state of it will the same. The default size of mempools is 300 mb so if the number of pending transaction exceeds 300 mb then the transactions with the lowest fees will be dropped hence the minimum. Looking at the above picture, there are between 5 and 10 blocks of 1 sat transactions in the pink band. This means that the mempool can grow to 310 mb, the 1 sat transactions will be purged, and and the minimum fee will be 2 sats which is the purple band.
8. A time based overview of incoming transactions
Why am I writing this?
I have mempool.space as my default page when I open my browser and this has become a growing annoyance of late. The mempool was overflowing with pending transactions during late 2017, it didn’t clear most of 2020, and then it became empty around Bitcoin 2021. People joked that all of the buyers and users of the chain were busy in Miami but Blockchain.com, the largest wallet provider to date, finally implemented Segwit for all of its users after almost 4 years on the dot. Can all of it be attributed to them? No because we are all responsible for Bitcoin’s success, shortcomings, and failures and we all need to discuss, understand, and move towards best practices.
This means that if you look at all of the fees we have had to pay over the last 4 years, it was because of poor stewards of the chain. If you think of all the time you had to wait for pending transactions to confirm, it was because of poor stewards of the chain. If you look at the half full blocks above, people are severely over paying for chainspace because of poor infrastructure, lack of understanding, and poor stewards of the chain. Even the transactions at 2 sats per vByte are overpaying for chain space if a block isn’t full.
Additionally, this is a bit of a dream at the moment but if all make better use of the base chain then there is a non 0 chance we’ll be able to add some form of confidential transactions. If we all use the tools afforded to us, the fee market on the base chain will be minimal. One way to secure the chain would be to make smaller blocks to induce a fee market to form. Another would be to softfork in some privacy technology where some of the information is hidden akin to what you see on Liquid. This would enhance the privacy of users while still maintaining the auditability of the supply cap.
How to utilize this information
When you make a transaction, you have to pay a fee to the miners but that doesn’t mean you should overpay for blockspace. Take a look at block 689246 which is the head of the chain. The average fee paid in that block was 69–605 sats per vbyte with the average fee being 74 sats. This means that everyone who paid more than 74 sats overpaid for that block.
One thing you can do is look at the fees paid in the first block in the queue. The fee’s range from 69–335 and average 75 sats per vbyte. If you were to make a transaction right now, you could either pay the current minimum of 69 sats or the average of 75. Your answer could vary based on when the last block was produced. Looking at the dashboard, it is 7 minutes “late” since Bitcoin’s blocks are suppose to be mined every 10 minutes. This could suggestion you lean towards the 69 sats since it should be mined any moment. But let’s say the opposite is true, and a block was just mined less than a minute ago. You could spend the average as new transactions will surely come in
That is a flawed assumption as it could have been mined a moment ago but you are waiting for the newest block to be sent to your node. It could take a few minutes for everyone’s node to be in sync again so you should always assume the next Bitcoin block is always 10 minutes away as you are the last node to get the message.
The default mempool size on your node is 300mb but some nodes have manually increased that cap. When there are a ton of transactions pending, your node will purge the transactions with the lowest transaction fees. If your node kept the default 300mb but there were 300mb worth of larger fees so your node may start purging every transaction willing to pay 5 sats per vbyte. This means that if you make a transaction for 4 sats per vbyte, most nodes will not even notice it so it will be a long time before it is included.
Another situation to be mindful of are runaway transactions. Look at the giant spike of purple on the below chart. Someone added 30 blocks of 3 sats per vbyte transactions on June 19th, 2021. Moments before the mempool was empty and you could automatically send a transaction for 1 sat per vbyte. Unfortunately, if you did that you would be behind that one person and there would be a minimum 5 hour wait as it would need to process 30 blocks first.
To make sure you don’t get caught behind a large consolidation like this, sse RBF and CPFP when you make a transaction. Replace By Fee ( RBF) is a feature in most modern wallets where you can rebroadcast the transaction. If you paid 2 sats per vByte and then the 30 blocks of 3 sat transactions come in, you can create a new version of the same transaction where you can increase the fee paid to 4 sats per vByte.
CPFP (Child Pays For Parent) is also a feature in modern wallets where you can use the unconfirmed UTXO in the mempool to broadcast a second transaction that will have a higher fee. Your first transaction at 2 sats has to wait at least 30 blocks but you could create a secondary transaction to yourself at the 4 sats. The thinking is that now a 4 sat transaction that is a promise to be made and can’t be mined now since the first transaction needs to be mined first. Miners will include the first, or parent transaction, below market rate at 2 sats because of the promised 4 sats transaction, or child transaction, is dependant upon it. Use a modern wallet with these features to protect yourself.
There are all kinds of reasons over payment occurs.
- If you are using an exchange that does not use Segwit, batch transactions, and is over paying transaction fees you should switch exchanges and we should name and shame them as a community.
- This is the price you pay to protect your privacy when using features like Time Lock and PSBT (Partially Signed Bitcoin Transactions).
- If you need to run across town to multiple locations to do a multisig transaction, you may want to look at the general fee market all week to get an average or be OK waiting until the weekend when it is generally easier to get a transaction included in a block.
- This post helps fix that
- Same as point number 1 but geared towards the user. If you notice this pattern then name and shame these wallets and consider getting a new wallet. This is easier than getting a new exchange and should be done.
- No modern wallet should use a static fee. Switch wallets immediately.
- This post touched on Lightning management
Things to do when the mempool is empty
You should move your coins to a more efficient address type.
There is no good reason to have any UTXOs in anything but Segwit and soon Taproot addresses. You are spending money now when it is cheap to save money on transaction fees later on when the mempool is busy. Let’s say it is December 2017 and you want to sell the top. If you send your UTXOs back to an exchange, you can save 54% on fees by having Segwit addresses ready to go. You are spending 1 sat per vByte ($0.00035) now when the cost to get into the next block was a minimum of 1,400 sats per vByte ($0.48). If you stacked sats every 2 weeks for a year, you would have to pay $1,847.04 for that transaction. Or you could pay $1.36 today to save $997.40 later.
Even if you are a complete maxi who says they’ll always hodl, do it anyway for your kids or grandkids. Let’s say you stack sats until you die in 30 years and you leave your kids a hardware wallet or multisig set up and Bitcoin is $1 million per coin. Odds are they are going to want to move those coins to their own hardware wallet, multisig set up, or whatever crazy DLC (Discrete Log Contract) is being used in the future. Well not only are you going to have the same issue mentioned above, but instead of it being $1.36 for one years worth of transactions, it now costs $1,828,569. $60,952 for the same transaction at the new price multiplied by 30 years you were stacking twice per month when you got paid. Even at 2 sats per vByte later, you still pay more waiting than doing one transaction now and your heirs doing it later.
Manage your Lightning node
Once you are done moving your UTXOs to more efficient address types, you may want to consider opening, rebalancing, or closing some Lightning channels. Lightning channels use a 2 of 2 multisig so opening and closing channels become very costly in a high fee environment.
Reduce your custodial risk
Move funds off of your exchange and learn to use a hardware wallet or maybe multisig. It does not make sense to withdraw $20 of Bitcoin if you have to pay a $5 to $50 transaction fee which means you’ll have to keep stacking until your withdrawal amount is worth it. This poses custodial risk as your coins are on the exchange longer so whenever fees are low, you should remove everything to a wallet where you control the private keys. If you don’t have a hardware wallet or multisig yet and want to try it, a low fee environment is the best time in case you screw something up. The only thing worse than losing $20 in a test transaction to a hardware wallet is losing $20 in Bitcoin and paying a $50 fee to learn that lesson.
Protect your privacy
When you look at all of your UTXOs, you may want to remove coins off of the exchange in multiple transactions instead of one. This way you can take advantage of the low fees and create a better spread of UTXO sizes in case your wallet supports Coin Control.
Conversely, you can break up UTXOs if you have a ton of larger ones. If you have 0.5 BTC, you could break that up into several 100k, 250k, 1 million, and a 10 million sat UTXOs. This way you can use the low fees now to protect your privacy later.
You may also want to look into coinjoining funds. Coinjoins are a type of transaction where multiple UTXOs are mixed so it obfuscates the probability of knowing where the transaction originated from. You can see from the image above that there are 5 inputs from 5 different users all spending 5 million sats. The UTXOs get coinjoined and you can no longer tell which of the 5 transactions originated from whom. Because of needing multiple inputs, the transaction costs will higher than a normal spend hence why you should do that when the mempool is clear.
In full disclosure, you should read up on coinjoins before using Samourai Wallet, Sparrow, or another protocol for two reasons. While it is entirely legal to protect your privacy and used these tools, some exchanges don’t want to take on the added risk of not knowing where the funds came from. Certain users such as myself are completely fine accepting coinjoined funds while some exchanges may ask for additional KYC information or outright close your account. Second, there are some nuances to handling coinjoined funds in a privacy preserving manner. If you aren’t versed in how to handle those UTXOs, you can break the obfuscation and have spent the extra fees on privacy for nothing by linking it back to the original UTXO.
Off topic but if you are the type of person who coinjoins their funds, make sure you disclose that to the friend or family member you are sending it to. To them it is a normal transaction but if they were to then send it back to an exchange to sell the top, they won’t be able to because of “suspicious funds” and they are going to blame you. Disclosing it is the polite thing to do. If anything it teaches them about coin control, UTXO management, and they can send that UTXO to cold storage until they understand what to do with it.
Philosophical and Evangelical
Eventually we will have Blocksize Wars II and when that happens, there will be a ton of new people who weren’t around for the first Block Wars. (If you are new, weren’t around between 2015-August 2017, you should, or looking for a good book to read, you should read The Blocksize War by Jonathan Bier) When that happens, we should take a serious look how the blockchain is currently being utilized and determine who is being a good steward of the chain. If you have some Bitcoin, then it is your responsibility to ensure Bitcoin does not suffer the Tragedy of the Commons.
Take a look at the most recent block (left) and an older block (far right). Both of these blocks were 1.58 mb in size yet block 689559 has over 2x the number of transactions in it than block 689553. Why does one contain 1,551 transactions and the other only contain 775? The difference between the two is that block 689553 has much larger transactions in it and it is most likely from far less efficient or sophisticated users.
What makes a large and inefficient transaction?
- The address type that your wallet uses.
Below is a very simple grid with 4 address types with the size of the transaction for two wallet types. As you can see, that regardless if you are using a single signature software or hardware wallet, it is more effective to use a Taproot address as an input compared to any other address types as it is a much smaller transaction with 58vB (61% smaller) than a non-segit address of 148vB. Comparatively, Taproot addresses as an output are 34% larger in size at 43 vB compared to other addresses. However, the real savings of Taproot are for more complex transactions such as a 2 of 3 multisig. The Schnorr part of the Taproot upgrade saves 81% of the blockspace.
What address am I using?
Non-Segwit or Legacy address: Starts with a 1
Wrapped Segwit or P2SH address: Starts with a 3
Native Segwit or segwit or bech32 v0 addresses: Starts with bc1q
Taproot or bech32 v1 addresses: Starts with bc1p
Once you know which kind of address you are using, you should start to migrate towards Taproot addresses. Not all wallets support Taproot yet since it was activated in November of 2021 but you can still migrate to Native Segwit addresses in the meantime.
2. Coincontrol and poor UTXO management
If you read the above and asked yourself, ‘what is an input vs an output’ then the answer is in regards to your UTXOs (Unspent Transaction Outputs) in your wallet.
If you look at the above transaction, you can see 3 inputs on the left from legacy addresses and it is being sent to one output which is the wrapped segwit address on the right. So now let’s consider two reasons why this transaction took place and why both were bad for two different reasons.
Coincontrol: This could be perfect coin control but it is most likely someone sweeping their funds to a new wallet. Why? In most wallets, they use the First In, First Out method where if you needed to send 0.023 BTC as seen above, the wallet will take the first 3 transactions in your wallet, and then send those three transactions regardless of amount to that address. The reason why it is not someone spending money and why it is most likely someone setting up a new wallet is the fact that there is no change.
The above transaction only has one output instead of 2. Some wallets let you select which UTXOs you want to spend which helps users save on fees and improve their privacy. But this means that the person had to have 3 inputs that exactly equalled 0.023 BTC to make the purchase they were doing down to the sat. Since that is highly unlikely, the more plausible explanation is they set up a new wallet which uses wrapped segwit. The unfortunate part is that this transaction was done in a block that paid 75 sats per vbyte average and to an outdated address format albeit it more efficient. This person should have waited to make a 1 sat transaction to sweep their wallet since there was no rush to save money and set up a wallet that is updated. Segwit was added in 2017 and it is 2021, your wallets should not be using anything but Segwit at this point.
Poor UTXO management: If your wallet has Coincontrol, you should use it to prevent poor UTXO management. Look at the above transaction and look at the amounts and the address types. Let’s say you lost a bet with a friend and you owe them 300,000 sats which is currently $100. This means that you exposed the fact that you have 8.27 BTC instead of using several smaller UTXOs that are closer to that amount. This saved you on fees but at the expensive of your privacy. Try to withdraw from exchanges with different UTXO sizes, even if it means keeping your coins on the exchange a while longer than you usually do to create some larger UTXOs.
Realistically, this is probably an exchange and someone bought $100. You know that someone didn’t send 8.26 BTC because of the two address types. The fact that it the input was a segwit address and it created two outputs of a segwit and wrapped segwit address, means the wrapped segwit of $100 is the receiver and the other output is the change because change addresses are the same as their input addresses.
Real world examples of inefficient uses of the chain and chain analysis
Wallet sweep to an old address: If you look at this transaction you have 11 legacy wallet inputs going to 1 legacy wallet output. This was someone sweeping a wallet. They took all of the old UTXOs and consolidated it into one UTXO.
What they should have done is spent them all one by one or clustered them into smaller sets to Segwit or Taproot addresses. Now all of those 11 spends are linked and anyone who sent funds to that person knows they have more than the original UTXO because they have been combined into one.
This is possibly an exchange but a more extreme example of the above. There are hundreds of inputs but they also swept that wallet to an older wallet address type. Always use more efficient address types if you ever sweep a wallet.
Leaking wallet details by the 2 of 2 multisig. Most multisigs use a larger quorum such as a 2 of 3 or 3 of 5 so seeing a 2 of 2 usually means it is a Lightning channel but this does not have a time lock on it. That means this person is actually using a 2 of 2 multisig wallet which is rare but they could be using wallets such as Green or Muun that default to a 2 of 2 wallet.
This is most likely a mining wallet. If you look at the inputs on the left, they are very small UTXOs of 5,000–30,000 sats. Moreover, it is going to the exact same address as most mining pools send payouts to a dedicated address instead of linking an xpub. This person should swap out the mining address to a Segwit or Taproot address as each of those inputs adds more and more fees when you try and sweep the wallet that starts with a 3. The vast majority of wallets will create a change address with the same address type as the coins being spent. Since the chain address is the same as the spending address, you know the address with the 3 is most likely the owner of this mining wallet.
For anyone asking the reasonable follow up question of, “How do you know this is a mining wallet and not a public address used for tipping” then you can click the address to look at the payment times. Each one of those 87 transactions is paid out 7 days apart. If it was a public tipping address then it would vary more widely by amounts as well.
If you are going to set a public tipping address I’d recommend using:
- a BOLT12 Lightning QR code (only available on c-lightning as of 11/28/21)
- a BIP 47 Paynym (only available on Samourai wallet as of 11/28/21)
- or a Segwit or Taproot address to save on fees as you won’t be able to get the privacy benefits of the first two options.
This is another example of either a wallet sweep or a larger spend. However, you see that each of the 20 inputs is part of a 2 of 3 multisig resulting in an 80 USD transaction fee. Once the hardware wallet companies implement Taproot AND multisig support for Taproot, you should do create a new multisig using Taproot addresses so you can dramatically reduce the fees and make your multisig transactions look like single sig transactions.
The below image is from Muum wallet. Can you spot the subtle difference here? Muun wallet as mentioned previously mentioned defaults to a 2 of 2 multisig wallet. Block explorers and chain analysis companies look at data onchain to understand who is sending what where. However, the third input is using a Taproot address (starts with bc1p) while the others are using Segwit (starts with bc1q). Because of the benefits of Taproot mentioned earlier, this multisig transaction now looks like a single sig transaction. Eventually, this privacy benefit will be available to everyone but you’ll have to move all of your existing UTXOs to Taproot addresses.
As always, if you have any feedback or corrections, please DM me.