Topic: Bitcoin transactions unconfirmed (Read 154 times)

And in this case, where the fee rate paid is still firmly within the default mempool limits and not low enough to be purged and the transaction is visible on all block explorers, rebroadcasting achieves nothing. ViaBTC's free accelerator also wouldn't work in this case since the fee paid is below the 10 sats/byte cut off they require.

For illustration: If you send all the bitcoin at the address 16qAvw1qDmJbAR9yeS54yrVe2r38d1T86K to another address within your wallet, and you want to boost the fee rate to 100 sats/vbyte (which is currently what you need for a relatively fast confirmation), the total fee you would have to pay for your two transactions together would be 416 bytes * 100 sats = 41,600 sats. Given that you have already paid 1,784 sats, your second transaction would need to pay 39,816 sats in fee. With a presumed size of 192 bytes for a 1-input-1-output legacy transaction, the fee rate for this second transaction would need to be ~208 sats/vbyte.

If you're in a hurry and is willing to pay a lot more fees, you can use CPFP. Assuming that you're controlling 16qAvw1qDmJbAR9yeS54yrVe2r38d1T86K, you can spend a transaction with a higher fee to bump your total transaction fees. The total size of both transactions would be 416 bytes if your child transaction is 1 input-1 output. You can calculate the fees that you need by a simple calculation; calculate the total fees needed for your desired fee rate and calculate the amount of fees your second transaction needs and thus its fee rate.

If you're willing to wait, then its fine. Fees can get much lower during the weekends, I made a <8sat/vbyte transaction during the weekends and it was confirmed fine within a few hours.

Number 2 and 3 on your list are ok... Number 1 however can potentially do more harm than good... You should only use it in very specific cases if you know what you're doing.
Why? Because the default node implementation's default mempool settings are to drop unconfirmed transaction from their mempool after 2 weeks. However, not all nodes have the same setting. Some might drop unconfirmed transactions after a day, some might have limited their mempool size and drop unconfirmed transactions when they store a couple Mb of other unconfirmed transaction, some might have a setting that only prunes unconfirmed transactions after a couple of months or if the mempool size grows over x Gb.
However, transactions stuck in the mempool due to low fees will eventually be dropped from all nodes. Once this happens, people should be able to re-spend the unconfirmed output used in the stuck transaction as if the stuck transaction never happened.
By rebroadcasting, you can slow this process down, making your stuck transaction "hang" in more mempools over a longer period of time, postponing the time where the funds "returns" to the user's wallet to be spent again (actually, if you look at the blockchain, the value never actually "left" the user's wallet).
I have actually seen this happen, people that had their unconfirmed transaction hanging for an extra week just because they were continuously using rebroadcasting tools.

You should only resort to rebroadcasting if the feerate dropped significantly since the time you broadcasted the stuck transaction, and the current average feerate is low enough to give your transaction a decent chance to end up in a block... If you rebroadcast your transaction less than a week after initially broadcasting it, it shouldn't have any effect at all since your transaction should still be in most mempools (unless a massive amount of transactions were broadcasted, and your transaction might have gotten pruned due to space constraints).

Thanks and this was very helpful. I did noticed the same thing yesterday and have actually confirmed to be because of low transaction fee and the transaction is still pending in my wallet but I also noticed that once  I clicked on the 3 dots besides the transaction Information it does ask me to replace transaction it gives me the following information
" ... You may increase the transaction fee in order for you transaction to be mined quicker" and I have an option to decrease the value am sending and increase the transaction fee. This is Enjin wallet by the way.

The absolute fee is meaningless, please keep the discussion on sat/vByte.
And the 8 sat/vByte OP has been using is indeed too low. Just look at https://mempool.space/ for the current fees.


The free accelerator that indeed works needs at least 10 sat/vByte, so this transaction doesn't qualify.
But you're right with CPFP: if OP is in a hurry and he owns one of the receiving addresses, he can spend that (unconfirmed) input with significantly higher fee than the current average and he will get both transactions confirmed.
If OP is not in a hurry, he should wait until the week-end when the fees use to drop and maybe then his tx will get confirmed (last week-end they've dropped until around 5 sat/vByte).

Wait for some time it takes a longer time for transactions to get confirmed when a couple of things happen, perhaps because of blockchain network congestion another cause for delay is the use of low transaction fees. It may take sometimes around 4 days for some transactions to get confirmed.

Yes it's being delayed because of the fee, since you mentioned fee 0.00001784 BTC ($1.15) which is far too low are per the current average.

as of today average fee of BTC transaction is 0.00029 BTC ~ $18.89

You have to wait for it and there is a chance it might get process when there will be free capacity in the network but it can take up to days or may be weeks.

Here are some online links which claim to accelerate your transaction.

1. https://bitaccelerate.com  (free, as per their claims they will rebroadcast the transaction via 10 Bitcoin nodes.)
2. https://pushtx.btc.com (not free, there might be some fee)
3. https://www.viabtc.com/tools/txaccelerator/ (free and paid both options)

I'm not sure how this works in the backend but there is concept called CPFP (Child Pays for Parent)  "if a new transaction is made with a high fee, building on top of the old transaction, most of the miners will include the whole chain of transaction in the block they're mining at.", so may be using this kind of protocol they can accelerate the transaction.

The fee you used is that of 8 sats/vbyte. Checking the Mempool chart in weekly mode view (https://jochen-hoenicke.de/queue/#BTC,1w,count), it stared being highly congested just around the time you sent your TX, so you’ll have to wait it out (no RBF option on the TX - (*)).

(*) https://blockchair.com/bitcoin/transaction/41c39100c0ec825ab02a298d6432c0fcffe757b9adeac6474a17e9af3f65ecb5

Thanks pooya
That was a lot of great info

I probably made the fee too low...

I will post my transaction:
https://www.blockchain.com/btc/address/3B4eeUd6pacEdnJfTfkfUUzPjcLSzmnGkr

There can be a couple of reasons for an unconfirmed transaction that we can't tell you without knowing the transaction ID.
The most common reason is paying low fees. Considering the fact that bitcoin price is rising and during rises there is an increased number of transactions being sent there is always a fee spike meaning when you pay fees that are lower than a certain level (the high priority fee) your transaction remains unconfirmed until the traffic decreases and mempool is cleared more.
You can see a visualization of the mempool here: https://jochen-hoenicke.de/queue/#BTC,24h,weight

Other reasons could be unconfirmed parent transaction, which is when you spend outputs that are not yet confirmed. Your transaction will remain unconfirmed even if you paid the high priority fee until the parent is confirmed.

Another less common reason for users of certain wallets like Electrum is that you may not have broadcasted the transaction. Some users save the tx locally by mistake and while they see it in their wallet the network doesn't know about it since the tx was never sent out.

Another less common reason I can think of is invalid transaction which could happen in some broken wallets (some phone wallets) where they connect to only one server and that server and the wallet are both broken and think the invalid tx is valid while the rest of the network simply rejects it as invalid so it can never confirm while the user sees it in their wallet (locally).

Hi guys,
I sent a BTC transaction yesterday... still unconfirmed ( 20 hours + )

Have y'all been experiencing this lately?