Pages:
Author

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

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
September 26, 2020, 06:02:57 AM
#31
That's the problem with most customer support where the employee doesn't have technical knowledge and only know how to solve common problem.

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!

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

I'm not sure how that company survive when malleability attack happened few years ago Undecided
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.

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
legendary
Activity: 2702
Merit: 3037
Top Crypto Casino
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.

legendary
Activity: 3472
Merit: 10611
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.
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.
legendary
Activity: 3038
Merit: 4418
Crypto Swap Exchange
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.
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.
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.
It would be annoying for the company to handle hundreds of support messages regarding uncredited deposits due to the malleability issue.
legendary
Activity: 2702
Merit: 3037
Top Crypto Casino
Wait what? They track an individual's payments based purely on TransactionID? Huh

That seems like a recipe for disaster!!?! And also prevents users from using RBF etc Undecided
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'm not sure how that company survive when malleability attack happened few years ago Undecided
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.
legendary
Activity: 3472
Merit: 10611
That's the problem with most customer support where the employee doesn't have technical knowledge and only know how to solve common problem.

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!
legendary
Activity: 2380
Merit: 5213
Wait what? They track an individual's payments based purely on TransactionID?
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.
HCP
legendary
Activity: 2086
Merit: 4361
Wait what? They track an individual's payments based purely on TransactionID? Huh

That seems like a recipe for disaster!!?! And also prevents users from using RBF etc Undecided
legendary
Activity: 3472
Merit: 10611
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.

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!
member
Activity: 92
Merit: 65
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.

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

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

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.
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" Tongue

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
HCP
legendary
Activity: 2086
Merit: 4361
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.
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" Tongue
legendary
Activity: 2534
Merit: 6080
Self-proclaimed Genius
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:

Quote from: Bitcoin Core console
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
legendary
Activity: 3472
Merit: 10611
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.
member
Activity: 92
Merit: 65
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.
legendary
Activity: 2268
Merit: 18711
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.
legendary
Activity: 3234
Merit: 5637
Blackjack.fun-Free Raffle-Join&Win $50🎲
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).
legendary
Activity: 2898
Merit: 1253
So anyway, I applied as a merit source :)
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. Cheesy
legendary
Activity: 2268
Merit: 18711
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.
copper member
Activity: 2114
Merit: 1814
฿itcoin for all, All for ฿itcoin.
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! Smiley

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

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
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/
legendary
Activity: 2170
Merit: 1789
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).
Pages:
Jump to: