Topic: How accurate is the fee estimation in Electrum? (Read 479 times)

I know. To make things worse, usually there's no documentation which makes migration become extremely difficult.


Looks like you forget about malleability attack performed by someone which attack every single transaction on mempool.

See https://bitcoinmagazine.com/articles/the-who-what-why-and-how-of-the-ongoing-transaction-malleability-attack-1444253640

Thank you ETFbitcoin for the link, I read the full article and it only proves my point so I guess you misunderstood my previous reply.
What I was trying to say is that a customer will gain nothing by performing a malleability attack because, in our case, he is making a deposit. All it can cause is some nuisance to the customer service.
The attack can cause monetary loss in case we were talking about withdrawal transaction IDs. In such case if the service monitors only the txids then the attacker can claim he didn't receive his money and asks for a refund (it can be more dangerous if the refund process was automated).
I hope you got my point.

However, I agree with all the comments above. This is the worst approach when it comes to monitoring transactions.

it is actually the laziest thing to do and considering the fact that many newcomers don't even know what RBF is i don't suppose these bad services get that many support tickets not to mention that they don't have that many users to begin with.
that may be the main reason why they haven't fixed their broken system.

Monitoring deposits based on the TXID is not the most efficient way about doing it. It would just cause unnecessary delay for the user and it would be a headache for them if the user decides to RBF due to low fees and whatnot.
It would be annoying for the company to handle hundreds of support messages regarding uncredited deposits due to the malleability issue.

Many of the services I used do this and some of them are long-established companies.  What I noticed is that those services either generate a new unique address for each new deposit or accept 0 confirmation transactions. I don't remember facing this problem when the deposit address is permanent.
In fact it makes sense if they have tons of addresses to monitor and they consolidate their inputs regularly.

I don't think it's in the customer's interest to conduct a malleability attack when using a service which accepts only the first seen transaction ID as valid.

not just the customer support employee but the owners sometimes are just as bad. you'd be surprised to see how many of these companies that keep showing up like mushrooms have no idea what bitcoin even is. they pay minimum amount to a newbie developer to set things up for them and that's about as far as their efforts go!

It's not the first time I've heard of such an issue.
They do track the address. But once a payment is made, they no longer track new transactions and wait for the first transaction to be confirmed. If the first transaction is removed, they consider the payment as failed.

Look at following thread. There was a same issue with Changelly. (The OP's problem was solved after contacting their support, off course.)

Please help with coins missing in transaction.

Wait what? They track an individual's payments based purely on TransactionID?

That seems like a recipe for disaster!!?! And also prevents users from using RBF etc

sadly there still are some bad services that follow the transaction ID instead of only watching the fresh and unique address they've generated for the customer, which should be the case everywhere. it is not that hard to change either which makes you wonder why they are not doing it after all this time!

Yes, you're right and I do use RBF but I am not sure if the company I sent my funds to would accept the deposit if the transaction ID changes.

I'll ask them before about this when I deposit the next time. Also, the last time it happened. The service I sent the funds to asks you to enter the transaction ID in the field to show that you have made the payment.

And which is why I had to do CPFP to make that transaction confirmed when it didn't confirm after 10 hours because I couldn't change the tx id.

The services who don't accept the BTC directly are usually not sure what went wrong. I deposited BTC at one such service and even after 6 confirmations, my money wasn't credited in my account.

When I asked their support. They told me that the transaction needs to get confirmed. And I told them that it already has 6 confirmations and it is unreturnable at this point. And they answered that it is not confirmed at their end.  

I told them that if a transaction is confirmed at one end, it is confirmed everywhere. And they told me to wait an hour.


I think what they're looking for is for the first fast confirmation, so they can credit the company whose using their services because they accept the payment in fiat and payment processors have to pay them the exact amount, even if the bitcoin price drops in the meantime. Which is why they don't accept multiple payments to the same address and/or delay.

But yes, it is not possible to know when your tx might get accepted, even if you pay the proper fee. But it is scary when they tell you that time has passed and your tx might get lost or returned. How would it get lost, I can never understand?

---

Btw guys, a new user in India forum has asked some advice on how to upgrade his Electrum wallet. Although 2 users have already given him good advice. If you guys have anything to share on the matter that might help, pls do so. Here's the link to the thread: https://bitcointalksearch.org/topic/portable-electrum-wallet-problem-5277692

Generally, most of the payment processors, they only care that a valid transaction was broadcast to the network within the timeframe that they show the invoice as being "valid"... They will generally just not process your order or credit your account until that transaction is actually confirmed.

Any service that issues an invoice for say "30 minutes" and expects that a user can guarantee confirmation in that time frame (regardless of fee paid) is asking for trouble. As you saw, there can indeed be time periods where a block is not found for over an hour!

Sometimes, miners are just "unlucky"

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:

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.

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.

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.

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).

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.

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.

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/

Their next block option is overpaying most of the times, I would not use it at all.
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).