Unconfirmed transaction for 160+ hours

[lukaexpl]

It is the following transaction.

https://blockchain.info/tx/98023274befba1e6726e7a6a1b73f122c83bf56692eb84f94d5754005df57953

I sent it from Blockchain.info wallet after reading that unconfirmed tx will be dropped if unconfirmed after 72 hours.
I would not mind getting the tx rejected by the network and trying with a higher fee but that is not happening.

I can not send it again from Blockchain.info wallet because it says that balance is zero on that address.

What are my options?

[1714834043]

1714834043

[1714834043]

1714834043

[1714834043]

1714834043

[BitNoLimit]

https://confirmtx.com/ use it to accelerate

[seasonw]

I see you set a very low fee on the transaction, so it just stucked in the queue until all other higher fee transactions done. But I don't think you can have it gone through so maybe you can try other solution like @itNoLimit suggested, but I never tried it before.

[milewilda]

It is the following transaction.

https://blockchain.info/tx/98023274befba1e6726e7a6a1b73f122c83bf56692eb84f94d5754005df57953

I sent it from Blockchain.info wallet after reading that unconfirmed tx will be dropped if unconfirmed after 72 hours.
I would not mind getting the tx rejected by the network and trying with a higher fee but that is not happening.

I can not send it again from Blockchain.info wallet because it says that balance is zero on that address.

What are my options?

4 sat/byte? Then expect it would be more longer for it to be recognize or broadcasted. Getting 1 confirmation would really be hard but as said above if all high priority transactions have been done then the smaller ones would be next. Priority would really be always normal for those who do paid up bigger fees and also this transaction cant be pushed via viabtc since it do have very low fee.

[lukaexpl]

Is there another tool where I could resend the transaction with a higher fee?

[squatter]

Is there another tool where I could resend the transaction with a higher fee?

Normally when I send a transaction with a fee that low, I flag it with opt-in replace-by-fee. So if it gets stuck like this, I can re-broadcast with a higher fee to get it immediately confirmed. It looks like you didn't do that here.

I think Peter Todd released a tool called doublespend.py (a Python script) that allows you to quickly double spend low-fee transactions. I think it should be somewhere in here: https://github.com/petertodd/replace-by-fee-tools

Alternatively, you can try pushing your transactions here:
https://pool.viabtc.com/tools/txaccelerator/
https://confirmtx.com/

[romani245]

https://confirmtx.com/ use it to accelerate

I've seen reports that this "service" just submits transactions to pool accelerators like the one run by ViaBTC. In other words, due to the size of the transaction, they're asking for payment to push the transaction.

If you don't want to deal with double-spending the inputs, then I would just submit to ViaBTC. You'll probably have to submit it several times before it goes through due to the current traffic.

[PVminer]

Is there another tool where I could resend the transaction with a higher fee?

The best would be to use replace-by-fee but you have probably not done it.

I you own the output  1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr, you can do "child pays for parent" https://bitcoin.org/en/glossary/cpfp. You spend from
1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr  to another address you own and pay a large enough fee. The miners cannot confirm the child without confirming the parent so in order to grab the new fee, they have to confirm the parent transaction. The new transaction (1 input, one output) will be 192 bytes, so two transaction will be 10094+192=10286 bytes. You paid  41830 satoshi in fees. If you pay now a 100000 satoshi fee, these two transaction will be 141830/(10286)=13.78 satoshi/byte. Still not a lot, it will take many hours or days to confirm (but it would have been instant 1-2 days ago). If you pay 1,000,000 satoshis (0.01 BTC), the combined fee will be 1041830/10286=101.28 sat/byte which should get confirmed immediately (even 60-70 sat/byte should be fine now). See, the current mempool statistics:
https://core.jochen-hoenicke.de/queue/#2d
But 0.01 BTC is quite a lot. Your choice. During weekends, there are usually less transactions and mempool is usually emptier and the running fees are lower. Last weekend it was 5 sat/byte so your original transaction was very close.  But nobody knows how full the mempool will be.

[lukaexpl]

Is there another tool where I could resend the transaction with a higher fee?

The best would be to use replace-by-fee but you have probably not done it.

I you own the output  1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr, you can do "child pays for parent" https://bitcoin.org/en/glossary/cpfp. You spend from
1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr  to another address you own and pay a large enough fee. The miners cannot confirm the child without confirming the parent so in order to grab the new fee, they have to confirm the parent transaction. The new transaction (1 input, one output) will be 192 bytes, so two transaction will be 10094+192=10286 bytes. You paid  41830 satoshi in fees. If you pay now a 100000 satoshi fee, these two transaction will be 141830/(10286)=13.78 satoshi/byte. Still not a lot, it will take many hours or days to confirm (but it would have been instant 1-2 days ago). If you pay 1,000,000 satoshis (0.01 BTC), the combined fee will be 1041830/10286=101.28 sat/byte which should get confirmed immediately (even 60-70 sat/byte should be fine now). See, the current mempool statistics:
https://core.jochen-hoenicke.de/queue/#2d
But 0.01 BTC is quite a lot. Your choice. During weekends, there are usually less transactions and mempool is usually emptier and the running fees are lower. Last weekend it was 5 sat/byte so your original transaction was very close.  But nobody knows how full the mempool will be.

Very useful advice. One last question: what wallets (hardware/software?) implement this child pays for parent model?

[boogersguy]

Is there another tool where I could resend the transaction with a higher fee?

The best would be to use replace-by-fee but you have probably not done it.

I you own the output  1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr, you can do "child pays for parent" https://bitcoin.org/en/glossary/cpfp. You spend from
1PyMz5LU7oGUeJwsanh3SGKPkc2vm66ntr  to another address you own and pay a large enough fee. The miners cannot confirm the child without confirming the parent so in order to grab the new fee, they have to confirm the parent transaction. The new transaction (1 input, one output) will be 192 bytes, so two transaction will be 10094+192=10286 bytes. You paid  41830 satoshi in fees. If you pay now a 100000 satoshi fee, these two transaction will be 141830/(10286)=13.78 satoshi/byte. Still not a lot, it will take many hours or days to confirm (but it would have been instant 1-2 days ago). If you pay 1,000,000 satoshis (0.01 BTC), the combined fee will be 1041830/10286=101.28 sat/byte which should get confirmed immediately (even 60-70 sat/byte should be fine now). See, the current mempool statistics:
https://core.jochen-hoenicke.de/queue/#2d
But 0.01 BTC is quite a lot. Your choice. During weekends, there are usually less transactions and mempool is usually emptier and the running fees are lower. Last weekend it was 5 sat/byte so your original transaction was very close.  But nobody knows how full the mempool will be.

I think the OP is the sender, not the receiver. So, might not have control over that output. But this is good info on CPFP nonetheless.

[PVminer]

Very useful advice. One last question: what wallets (hardware/software?) implement this child pays for parent model?

Any wallet that allows spending unconfirmed inputs and selecting which inputs to spend. I know that Electrum can do it but there may be many more (Bitcoin Core can send it if the unconfirmed output is change). Electrum has even an extra  "child pays for parent" menu in the transaction tab that simplifies it.  

[PVminer]

I think the OP is the sender, not the receiver. So, might not have control over that output. But this is good info on CPFP nonetheless.

You can do CPFP as a sender if you have the change and spending the change. But in this case, there was no change so only receiver can do CPFP.

[Thirdspace]

free accelerate thru viabtc or confirmtx won't work, way off their requirements
if it was 10+sats/byte might have greater chance to get confirmed
the only way you can do right now probably by trying double spend it
but looking at the size, you would better send them in batches (or consolidate them first)
I'm not quite sure about this but it seems with same low fee rate,
smaller size txs get confirmed a lot faster than those bigger size txs

[PVminer]

smaller size txs get confirmed a lot faster than those bigger size txs

It's not true. It's just a matter of fee per byte. Sure, a 226 byte transaction with a barely enough fee can fit into 999500 byte block while 10k will not but it is a cosmetic difference. If your fee is not worse than the transaction list sorted by fee at the 990000th-byte position, it will be mined. There are regularly >50kB transactions like thishttps://btc.com/1f2d5f70d409d3514de9f7c43bc6fc66863b450d18fff6abc068e72811588493 mined

[lukaexpl]

I ended up using confirmtx.com

Did not happen automatically within 24 hours, their email support is wrong when you use coinpayments gateway, found the guy on this forum. He said he would check it. It got confirmed some 12 hours later. Wheter it was him or just a random miner picking it up is impossible to tell.

Summary is: it happened 11 days after being broadcasted.

The scary thing is that the network did not drop it. I would much rather prefer if there was a hardcoded limit when transactions get dropped.

[PVminer]

I ended up using confirmtx.com
Did not happen automatically within 24 hours, their email support is wrong when you use coinpayments gateway, found the guy on this forum. He said he would check it. It got confirmed some 12 hours later. Wheter it was him or just a random miner picking it up is impossible to tell.

In my humble opinion, this site works just like a site that sells "a rock that protects from tigers". They do nothing, in many cases the transaction will be confirmed, and in the worst case, they can refund the fee.

The scary thing is that the network did not drop it. I would much rather prefer if there was a hardcoded limit when transactions get dropped.

There is no such thing as hardcoded time limit in the distributed system. How you are going to enforce it? There is no common time, everybody sees everything differently. Somebody may see your transaction immediately. Somebody may see it later. The former group may forget about it but the latter will retransmit it. Somebody may store and retransmit the transaction just for fun. And you cannot ban retransmission. Otherwise, you won't be able to make the same transaction again. Moreover, storing a database of already transmitted transactions would by a DoS weak point. Somebody can flood the network and exhaust the memory of the nodes.

The current situation is the best one. Unless somebody double spends before the transaction is confirmed, the transaction should be considered final. Double spending is the only thing that can "reverse" a transaction.

[lukaexpl]

Thanks for the explanation PVMiner. Still I do not understand why it would add any complexity if the transaction got dropped lets say 1 week after being initially broadcasted.

Regarding confirmtx.com. I wrote an email to the former address that I found and I got back the reply back saying pretty much "The new owner is a fraud. Warn others"

[PVminer]

Thanks for the explanation PVMiner. Still I do not understand why it would add any complexity if the transaction got dropped lets say 1 week after being initially broadcasted.

Because there are no good ways to enforce it. And if you cannot enforce it, it's better not to have a false idea that there is such a rule. The current rule in the Core is that transactions older than 14 days are removed from the mempool. But you cannot be sure if anyone follows that rule.

Enforcing the rule would make it worse not better. Because you would have to remember that a certain transaction happened at certain time. And by doing that you are opening a possibility of a denial or service attack by flooding the network with many transactions. Currently if you flood the network, the nodes will remove the lowest-fee-per-byte transactions and you cannot exhaust the nodes memory.

[rule144]

Great information guys.  The only time I've ever run into this is using myetherwallet and sending tokens etc, I always double the gas.