Bitcoin Forum

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.

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.

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.  

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?

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
https://i.imgur.com/2qsnCsD.png

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.


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.


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


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)  :D I think it is possible that it won't get confirmed this year.

You can reduce such occurance by reducing the ETA. I use mempool mainly and go for 1MB when I need it urgently.
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.

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.

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 (https://www.viabtc.com/tools/txaccelerator/) or BTC.com (https://pushtx.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.

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) :D

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.

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

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! (https://bitcointalk.org/index.php?topic=2848987.0)
• Bitcoin transaction fees (in sats/kb). Sunday, Saturday are best to move BTC (https://bitcointalk.org/index.php?topic=5250569.0)

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

https://b10c.me/data/mo/mo2-bitmex-broadcast/effect-observed-feerate.png


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

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.

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. :D

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

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.

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.

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.

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:

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" :P

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.  ;D

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


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://bitcointalk.org/index.php?topic=5277692.0

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!

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 :-\

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. (https://bitcointalk.org/index.php?topic=5261143)

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!

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.

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.

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.