How accurate is the fee estimation in Electrum?

[Melloiga]

I'd say not accurate at all. I created a transaction and ETA said that it will get confirmed in 2 blocks with the suggested fee and it has been 3 hours and 10 blocks since then and I don't know how much longer it will take to get confirmed.

And it was a time bound transaction and the page I sent it to says that the time has passed and the deposit might get lost or returned.

And this is not the first time it has happened. I sent a tx before and ETA said it would get confirmed within 5 blocks and I wasn't in a hurry. So, I sent it with that fee. And in the morning after 10 hours later it was still unconfirmed and I had to do CPFP on the change balance address to get it to confirm.

Any way to fix this? I am on the latest Electrum btw. Also, I can't do RBF because the transaction would change and I will lose the deposit. And I don't want to keep doing CPFPs.

[1714947123]

1714947123

[1714947123]

1714947123

[1714947123]

1714947123

[1714947123]

1714947123

[1714947123]

1714947123

[ranochigo]

I'll say it's as good as it can get. Fee estimation utilises the mempool's recent fee statistics to guesstimate the suitable fee for you. Unfortunately, this entails having the downside of the software to not be able to predict future fees.

When I pay lower fees, I find it better to assume the worst case scenario since it's more likely for the mempool to spike suddenly (like what just happened) within the timeframe. There's no model to predict the fee market and that's the best estimate that can be given. If the algorithm were to be more forgiving, people would complain that they're paying more than required for most of their transactions.

[Pmalek]

Your best bet is to check the current status of the mempool yourself before sending coins to determine what should work for a quick confirmation.

Go to https://jochen-hoenicke.de/queue/#1,2h and pay attention to the last graph on the site. Place your cursor all the way to the far right to see the fee ranges of all currently unconfirmed transactions that are waiting to be picked up. For a quick confirmation in the next few blocks, I would say you need 50-60 sat/vbyte right now. Unless there is a sudden spike of transactions with much higher fees, that should be more than enough.

Personally, I would never pay such fees, unless it is absolutely necessary.  

[jackg]

The fee estimation is only based on the past.

It's possible to change the fee estimator to be within a certain mempool constraint also which might be helpful for getting it within the next block but I mainly use the android version of electrum so I don't know how to do it on a PC.

I don't know also why you say you couldn't rbf? Surely they'd just accept the new transaction on the other end?

[Bitcoin_Arena]

Just like your topic says, it just an estimation and not the exact number of blocks in which your transaction will get confirmed. The state of unconfirmed transactions in the mempool keeps changing as new transactions with higher fees keep coming in and the time taken to confirm the next bitcoin blocks is something rather random. So, If the next block takes over 30 minutes to get confirmed then be sure you transaction has been pushed a little further away from the mempool tip than it was 30 minutes ago when you broadcast the transaction.

I suggest you use the "In the next block" option next time, again it's not a guarantee but still your transaction stands a higher chance of getting confirmed quicker

I prefer the Mempool fees estimation option along side a couple of tools like mempool.space. They give a better picture of the mempool in real time unlike ETA which is mostly based on the previous block

[Melloiga]

I don't know also why you say you couldn't rbf? Surely they'd just accept the new transaction on the other end?

They use a payment processor and don't accept BTC directly and it says specifically to send only one transaction to that address and that too within a time frame and if you send more than that it might not get credited because the conversion price might change in the meantime.

There's no model to predict the fee market and that's the best estimate that can be given. If the algorithm were to be more forgiving, people would complain that they're paying more than required for most of their transactions.

That's a problem then. Especially when you need a tx to get confirmed quickly. I usually do end up sending with higher using same ETA and block explorer telling that I paid like 400% higher fee.

Your best bet is to check the current status of the mempool yourself before sending coins to determine what should work for a quick confirmation.

Go to https://jochen-hoenicke.de/queue/#1,2h and pay attention to the last graph on the site. Place your cursor all the way to the far right to see the fee ranges of all currently unconfirmed transactions that are waiting to be picked up. For a quick confirmation in the next few blocks, I would say you need 50-60 sat/vbyte right now. Unless there is a sudden spike of transactions with much higher fees, that should be more than enough.

Personally, I would never pay such fees, unless it is absolutely necessary.  

Yes, I was lazy to do it. I should have checked such websites which tell the best current fee.

I suggest you use the "In the next block" option next time, again it's not a guarantee but still your transaction stands a higher chance of getting confirmed quicker

I prefer the Mempool fees estimation option along side a couple of tools like mempool.space. They give a better picture of the mempool in real time unlike ETA which is mostly based on the previous block

I do generally use that option but it was sending with way higher fee in the last couple of transactions I did. Like fee up-to 4 USD for 100 USD tx and I moved the scroller to the left and it said within 2 blocks which wasn't too bad, so I sent it with that option and it got stuck.

I'll try the mempool option next time. I couldn't understand what it meant is why I didn't give it a try. So 0.1 MB from tip means it will get picked up as soon as possible? like in next block and 0.2 within 2 blocks?

My current stuck transaction says (9.36 vMB from tip)  I think it is possible that it won't get confirmed this year.

[ranochigo]

That's a problem then. Especially when you need a tx to get confirmed quickly. I usually do end up sending with higher using same ETA and block explorer telling that I paid like 400% higher fee.

You can reduce such occurance by reducing the ETA. I use mempool mainly and go for 1MB when I need it urgently.

I'll try the mempool option next time. I couldn't understand what it meant is why I didn't give it a try. So 0.1 MB from tip means it will get picked up as soon as possible? like in next block and 0.2 within 2 blocks?

Nope. Each block theoractically can accommodate 1MB of transaction. It simply means whether your transaction would be confirmed within the next X mb worth of blocks. It isn't accurate as with any fee prediction but it is a different way to present things.

[Bitcoin_Arena]

I do generally use that option but it was sending with way higher fee in the last couple of transactions I did. Like fee up-to 4 USD for 100 USD tx and I moved the scroller to the left and it said within 2 blocks which wasn't too bad, so I sent it with that option and it got stuck.

I'll try the mempool option next time. I couldn't understand what it meant is why I didn't give it a try. So 0.1 MB from tip means it will get picked up as soon as possible? like in next block and 0.2 within 2 blocks?

My current stuck transaction says (9.36 vMB from tip)   I think it is possible that it won't get confirmed this year.

If you look at the past blocks in https://mempool.space, you can  see that the average bitcoin block size is around 1 MB though some blocks can even go up to 1.6+ MB
So if you transaction is at 0.1 MB or 0.2 MB from the tip, it means that should a block get mined in the next few seconds or a couple of minutes, you transaction stands a high chance of getting included in that block.

The longer the next blocks takes from getting mined while more unconfirmed transactions with higher fees keep coming into the mempool, the further your unconfirmed transaction is pushed away from the tip. So having a transaction closer to the tip of the mempool at the time you broadcast it helps to keep your transaction with in the range of the next block in a way.

Your TX might get confirmed in 24 hours.

[sheenshane]

Have you tried at least a free Bitcoin Transaction Accelerator?

If you don't want to use CPFP which is the RBF option of boosting transaction, you might use the Bitcoin accelerator, there is free and or the best is you pay an extra fee to accelerate the transactions. You can use either ViaBTC or BTC.com, but this doesn't have any guarantee to fasten the transaction, it will remain on the waiting line to be getting confirmed.

I think there's nothing you can do is to wait when it will confirm. By the next time, even you will pay $4 for a single transaction would be fine as long as you will not wait a long time. If you can see, the market congestion at this moment has been rapidly increased.

[Melloiga]

Right, this is all very bad. I sent a tx with proper fee but the block got late in coming and during that time people sent txs with more fees and so there txs got included in the next block and not mine. This isn't fair at all.

I think it should be first come first serve basis and not based on greed of miners for higher fee. At-least if a tx is sent with a proper fee. If it is lower or nil then by all means send it to the end but if a tx is paying at-least 1% of the transacted amount then it should get included in next 3 blocks at the very least.

And 4 USD doesn't seem bad if you're doing like 1tx in a week but when you're doing 4 in a day, it starts to look big. I'll give accelerators I try. Thanks all!

Btw, my stuck tx on block explorer :ETA   unknown (9.97 vMB from tip)

[hosseinimr93]

Nope. Each block theoractically can accommodate 1MB of transaction.

If I'm not wrong, theoretically the size of every block can be up to 4 MB.
The block size cannot be bigger than 1 MB if all transactions in the block include only legacy addresses. If Segwit addresses are used, the block size can be bigger than 1 MB.
Please correct me if I am wrong.

[joniboini]

I suggest you use the "In the next block" option next time, again it's not a guarantee but still your transaction stands a higher chance of getting confirmed quicker

Their next block option is overpaying most of the times, I would not use it at all.

I prefer the Mempool fees estimation option along side a couple of tools like mempool.space. They give a better picture of the mempool in real time unlike ETA which is mostly based on the previous block

This is a better idea. If you need your transaction to get confirmed on the next block, see whether there are a lot of transactions on the mempool or not, if not, you could probably get away with setting your fee to 1-2 sat+the lowest fee on the current candidate block. If not, you'd probably need to add 10 sats or more (also depends on how quick the next block will be generated).

[Bitcoin_Arena]

Right, this is all very bad. I sent a tx with proper fee but the block got late in coming and during that time people sent txs with more fees and so there txs got included in the next block and not mine. This isn't fair at all.

I think it should be first come first serve basis and not based on greed of miners for higher fee. At-least if a tx is sent with a proper fee. If it is lower or nil then by all means send it to the end but if a tx is paying at-least 1% of the transacted amount then it should get included in next 3 blocks at the very least.

And 4 USD doesn't seem bad if you're doing like 1tx in a week but when you're doing 4 in a day, it starts to look big. I'll give accelerators I try. Thanks all!

Btw, my stuck tx on block explorer :ETA   unknown (9.97 vMB from tip)

Well that's how the Bitcoin network was designed and it's what has kept it running for the last 10 years. If transactions were to be confirmed on a first come first serve basis then people wouldn't see any reason to pay more than 1 sat/vbyte and this would be catastrophic to the Bitcoin network. Miners wouldn't profit and therefore they would abandon minig bitcoin.

There are a few threads that can help know how you can spend less on bitcoin fees

• [Sept 2020] Fees are low, use this opportunity to Consolidate your small inputs!
• Bitcoin transaction fees (in sats/kb). Sunday, Saturday are best to move BTC

Monday is one of the days where the unconfirmed transaction count tends to spike after a less busy weekend.

There are also certain times of the day when fees tend to spike. You should probably try spending your bitcoins before or way after those times. Like everyday at 13:00 UTC, bitmex broadcasts a batch withdrawal of thousands of transaction with relatively high transactions fees which flood the mempool for a few hours affecting how long other transactions with lower fees are going to be confirmed




Here are details of the research  if you are interested https://b10c.me/mempool-observations/2-bitmex-broadcast-13-utc/

[o_e_l_e_o]

If I'm not wrong, theoretically the size of every block can be up to 4 MB.

Theoretically, if the block included a single P2WSH transaction with an enormous script which took up the entirety of the block with witness data, then you could get within a few hundred bytes of the 4 MB limit (but not actually hit the 4 MB limit). In reality though, a block which is filled with SegWit transactions would be somewhere in the region of 2 to 3 MB.

OP, have a look at the last graph here: https://jochen-hoenicke.de/queue/#1,8h

Judging by the timing of your post and you waiting 3 hours, you presumably made the transaction somewhere around 12.30 UTC. Electrum gave you a fee to be confirmed within 2 blocks. A couple of things then happened:

First of all, there was a 27 minute block time, followed immediately by a 90 minute block time (between blocks 649370 and 649371).
Secondly, Bitmex dumped 4 MB of transactions in to the mempool at 13.00 UTC.

The fee Electrum gave you for a 2 block confirmation would have been accurate, provided the next two blocks were found in the average time of 10 minutes. It is impossible to predict that a 90 minute block time would hit, which led to the mempool filling up greatly and your transaction being pushed way lower.

This is not Electrum's fault - this is simply bad luck.

[TheUltraElite]

Recently I had used Electrum to send a 10$ transaction and cheaped out on the fee and had to wait for more than 24hours. I believe the fee estimation system in Electrum is not that good comparing with the mempool congestion.

The better alternative would be to use the online fee checking sites to decide what might be an optimum fee for the optimum speed of transaction and confirmation (subjectively). You dont want to make your friend on the other side wait for a day while you also dont want to waste too much fee on something that can receive the coins anytime you send them.

Another thing is that the concept of "accelerator" is something that I dont trust completely. Previously we had some illegitimate services in this forum who got busted for running such a scheme. They used to ask for tip and negative trust those who did not send them a fee. They did not even do anything in reality just used the ViaBTC accelerator (now defunct). I would like to see a legitimate accelerator service, if in reality something like that was even possible.

[Lucius]

Have you tried at least a free Bitcoin Transaction Accelerator?

In this particular case, OP would not benefit from the accelerator either - because, as o_e_l_e_o wrote, it was really bad luck, because how else to call the case that in a period of two hours we have only two blocks. Specifically for ViaBTC, they on average find a block every 4-5 hours, but have certain requirements for the transaction to be accepted at all (only 100 transactions every hour +minimum fee of 0.0001BTC / KB).

[o_e_l_e_o]

I believe the fee estimation system in Electrum is not that good comparing with the mempool congestion.

The fee estimator on Electrum is actually one of the best out there, in that it gives you different options to choose from (estimated number of blocks to wait, or position in the mempool), and for each option you can still choose a priority from next block to 25 blocks or within 0.1 MB to within 10 MB. This is far superior to most websites/wallets/exchanges which simply give a "suggested fee" which is the same for everyone, or maybe a high/low priority fee.

The problem Electrum's fee estimator suffers from is a problem that all fee estimators suffer from - it cannot predict the future. The fee it suggested in this case was probably entirely appropriate, but it is impossible to predict that the next block will take 90 minutes to be found. Even a transaction with a fee of 40 sats/vbyte, putting it 0.01 MB from the tip, was over 3 MB deep by the time the next block came around.

Even if OP had used https://jochen-hoenicke.de/queue/#1,8h to choose a fee instead as you suggest (and I would usually agree) it wouldn't have made a difference in this case.

[Melloiga]

Hi all, the transaction got confirmed sometime during the night. When I woke up it had already 13 confirmations, so that's that.

And yes, I guess it was not fault of Electrum but a series of unfortunate events that happened exactly after I sent that transaction which lead to it getting stuck.

But the good news is, the site I sent it to credited my account, even though the transaction came in very late. So, everything went well in the end.

Thank you to everyone for replying and sharing their knowledge on this matter. I really learnt a lot about mempool and how and what gives transaction priority.

I suppose the only certain way of making sure that your transaction gets accepted as soon as possible is to keep overpaying the fee.

[pooya87]

I suppose the only certain way of making sure that your transaction gets accepted as soon as possible is to keep overpaying the fee.

not necessarily. you can always pay the minimum amount for a high priority transaction but mark it as RBF and if it didn't get confirmed in the next block and if you made sure that the mempool had indeed grown (eg. you can do it on https://jochen-hoenicke.de/queue/#0,24h) then you can simply bump its fee before the next block is found to the new minimum for high priority.

keep in mind that each time you bump your fee your transaction ID changes and although majority of services that i have seen have no issue with RBF and those that had bugs have fixed it already you may want to know what kind of service you are using in case your payment is to such services for a purchase for instance, otherwise deposits in your accounts like on an exchange have no issue.

[nc50lc]

Nope. Each block theoractically can accommodate 1MB of transaction.

If I'm not wrong, theoretically the size of every block can be up to 4 MB.
The block size cannot be bigger than 1 MB if all transactions in the block include only legacy addresses. If Segwit addresses are used, the block size can be bigger than 1 MB.
Please correct me if I am wrong.

Right, 4MB maximum block size is based from the "Weight" so more SegWit transactions will make a block higher than 1MB in disk.
But the maximum block size in virtual Bytes is 1vMB.

To support ranochigo's post: Since we're talking about Electrum's fee estimation, we have to use "(virtual) MB from tip" when using "mempool fee estimation".
Because Electrum actually computes the vBytes of its transactions but they are being displayed as Bytes
and the servers which mostly uses Bitcoin core may be computing its mempool size in vBytes based from this:

getmempoolinfo

Returns details on the active state of the TX memory pool.

Result:
{                           (json object)
  "loaded" : true|false,    (boolean) True if the mempool is fully loaded
  "size" : n,               (numeric) Current tx count
  "bytes" : n,              (numeric) Sum of all virtual transaction sizes as defined in BIP 141. Differs from actual serialized size because witness data is discounted