Unconfirmed transaction stuck in queue

[mufa23]

First time this has happened to me, so maybe I'm panicking a bit more than I should.

I added a paper wallet to my Bitcoin-QT client using the RPC importing private key command. It didn't add the address to my list of receiving addresses (I'd image it is some invisible address that's on the backend of the client saved to the wallet.dat; hidden from the user). However, the Bitcoins loaded into my client like they should have. So no worries there.

I sent some of the Bitcoins to an exchange, then deposited the rest into another offline paper wallet. I had some Bitcoin remaining (0.64225423 to be exact), and thought I'd send them to my main address (one listed in my sig) to be sure they were in an address that was saved on my wallet.dat file. For some reason, sending to myself didn't require a transaction fee. So I just sent them anyway without giving it a second thought.

It has been ~18 hours or so now, and not a single confirmation. I don't have the funds in my "Balance" or "Unconfirmed". If I look at Blockchain now, I can see them queued in the thousands, and seems to be getting pushed further and further back. https://blockchain.info/tx/f1c2b0df2f66677d949437846403ac72a5fe850fea1f79e22f80dece3a164c47

I assume after a few days, it will be purged and returned back to their appropriate addresses. And I can resend it later with an appropriate fee?

Am I doing something wrong? Am I about to blackhole ~0.6BTC? I'll get those coins back eventually, right?

[1714920602]

1714920602

[mufa23]

Giving this a bump. I need help

[Remember remember the 5th of November]

First time this has happened to me, so maybe I'm panicking a bit more than I should.

I added a paper wallet to my Bitcoin-QT client using the RPC importing private key command. It didn't add the address to my list of receiving addresses (I'd image it is some invisible address that's on the backend of the client saved to the wallet.dat; hidden from the user). However, the Bitcoins loaded into my client like they should have. So no worries there.

I sent some of the Bitcoins to an exchange, then deposited the rest into another offline paper wallet. I had some Bitcoin remaining (0.64225423 to be exact), and thought I'd send them to my main address (one listed in my sig) to be sure they were in an address that was saved on my wallet.dat file. For some reason, sending to myself didn't require a transaction fee. So I just sent them anyway without giving it a second thought.

It has been ~18 hours or so now, and not a single confirmation. I don't have the funds in my "Balance" or "Unconfirmed". If I look at Blockchain now, I can see them queued in the thousands, and seems to be getting pushed further and further back. https://blockchain.info/tx/f1c2b0df2f66677d949437846403ac72a5fe850fea1f79e22f80dece3a164c47

I assume after a few days, it will be purged and returned back to their appropriate addresses. And I can resend it later with an appropriate fee?

Am I doing something wrong? Am I about to blackhole ~0.6BTC? I'll get those coins back eventually, right?

Fees 0 BTC

What did you expect? You have 3 dust inputs that have caused this, and no fee.

[DannyHamilton]

I assume after a few days, it will be purged and returned back to their appropriate addresses. And I can resend it later with an appropriate fee?

No.  Bitcoin-Qt will continue to broadcast the transaction.  Eventually it will probably confirm, but that could be days or weeks from now. You could use pywallet to remove the transaction from your wallet, and then wait a few days for the network to forget about the transaction.  After that you could create a new transaction if you want to.

Am I doing something wrong?

That depends on what you mean by "wrong".  You should probably set a 0.0001 BTC minimum fee in your wallet to prevent such issues in the future.

Am I about to blackhole ~0.6BTC? I'll get those coins back eventually, right?

If you leave it alone, the transaction will most likely confirm eventually.  It could be a very long time though.

[mufa23]

I assume after a few days, it will be purged and returned back to their appropriate addresses. And I can resend it later with an appropriate fee?

No.  Bitcoin-Qt will continue to broadcast the transaction.  Eventually it will probably confirm, but that could be days or weeks from now. You could use pywallet to remove the transaction from your wallet, and then wait a few days for the network to forget about the transaction.  After that you could create a new transaction if you want to.

Am I doing something wrong?

That depends on what you mean by "wrong".  You should probably set a 0.0001 BTC minimum fee in your wallet to prevent such issues in the future.

Am I about to blackhole ~0.6BTC? I'll get those coins back eventually, right?

If you leave it alone, the transaction will most likely confirm eventually.  It could be a very long time though.

Yeah, pretty retarded of me... It was late, and just wasn't giving it a second thought. I don't want to screw around with anything more than I already have. I've added a permanent fee, and will try to wait it out for a week or so before I give pywallet a try.

Thanks for the reply!

[mufa23]

The transaction ID has removed itself from blockchain.info now: https://blockchain.info/tx/f1c2b0df2f66677d949437846403ac72a5fe850fea1f79e22f80dece3a164c47

I guess I should go ahead and try to remove it from my wallet with pywallet?

[Remember remember the 5th of November]

The transaction ID has removed itself from blockchain.info now: https://blockchain.info/tx/f1c2b0df2f66677d949437846403ac72a5fe850fea1f79e22f80dece3a164c47

I guess I should go ahead and try to remove it from my wallet with pywallet?

You can try. Then rebroadcast with a higher fee?

[mufa23]

Im at work right now posting from my phone. But I "think" i made a backup of my wallet.dat after importing the private key, but before i sent the coins without the fee. Would loading this saved wallet with the --rescan option work?

[billym2k]

I had the exact same issue, and right after blockchain dropped it and I reopened Bitcoin-QT, the transaction went through, go figure.

[mufa23]

Alright, I loaded in my backed-up wallet, and I got my coins back!

I sent them to BTC-e with a fee of BTC0.001, and it's stuck again... The transaction won't even show up on blockchain.info

[MoonShadow]

Alright, I loaded in my backed-up wallet, and I got my coins back!

I sent them to BTC-e with a fee of BTC0.001, and it's stuck again... The transaction won't even show up on blockchain.info

That's probably because there are now two different transactions that attempt to spend the same coins, so any nodes that saw the first one (almost all of them) would regard the second one as invalid and refuse to forward it.  You're just going to have to wait until the delayed transaction gets picked up.

[mufa23]

Alright, I loaded in my backed-up wallet, and I got my coins back!

I sent them to BTC-e with a fee of BTC0.001, and it's stuck again... The transaction won't even show up on blockchain.info

That's probably because there are now two different transactions that attempt to spend the same coins, so any nodes that saw the first one (almost all of them) would regard the second one as invalid and refuse to forward it.  You're just going to have to wait until the delayed transaction gets picked up.

Understandable. Will leaving my client running help any? Or will I have to leave it open anyway to continue broadcasting the newer transaction(s)? I figure I'll have to leave it running the next few weeks to help fix all my screw-ups.



(Unrelated: Would you message me the quote in your sig? I can only read part of it. Some of it is cut-off. Just curious what it says.)

[DeathAndTaxes]

That's probably because there are now two different transactions that attempt to spend the same coins, so any nodes that saw the first one (almost all of them) would regard the second one as invalid and refuse to forward it.  You're just going to have to wait until the delayed transaction gets picked up.

Understandable. Will leaving my client running help any? Or will I have to leave it open anyway to continue broadcasting the newer transaction(s)? I figure I'll have to leave it running the next few weeks to help fix all my screw-ups.

Either way will work but if you can I would just leave the client running.   You can't control other nodes all you can do is "talk to them" through your client (happens automatically).  Right now the majority of the network believes your old tx is valid and will reject the new one.  37 nodes believe the new tx is valid and will reject the old one.  So the network is "split" eventually one of those tx will end up in a block.   Since other nodes know about your tx and will continue to try and relay it you probably can close your client but having your client broadcasting is one more node "on your side". 

IF all that was excessive.  Simple version:
If you can leave the client running, do so as it can help spread the new tx faster.  
If you can't leave the client running you should be fine as 37 peers know of the new tx however if they all went offline your tx might not confirm until you start your client up again.

[mufa23]

That's probably because there are now two different transactions that attempt to spend the same coins, so any nodes that saw the first one (almost all of them) would regard the second one as invalid and refuse to forward it.  You're just going to have to wait until the delayed transaction gets picked up.

Understandable. Will leaving my client running help any? Or will I have to leave it open anyway to continue broadcasting the newer transaction(s)? I figure I'll have to leave it running the next few weeks to help fix all my screw-ups.

Either way will work but if you can I would just leave the client running.   You can't control other nodes all you can do is "talk to them" through your client (happens automatically).  Right now the majority of the network believes your old tx is valid and will reject the new one.  37 nodes believe the new tx is valid and will reject the old one.  So the network is "split" eventually one of those tx will end up in a block.   Since other nodes know about your tx and will continue to try and relay it you probably can close your client but having your client broadcasting is one more node "on your side".  

IF all that was excessive.  Simple version:
If you can leave the client running, do so as it can help spread the new tx faster.  
If you can't leave the client running you should be fine as 37 peers know of the new tx however if they all went offline your tx might not confirm until you start your client up again.

Not excessive at all! I appreciate your detailed explanation. Thanks!

And up to 67 nodes now.