All my coins stuck in unconfirmed transactions

[skis]

Yesterday I made a new wallet and sent all my coins to it but they never showed up. I looked in on bitcoincharts and saw that it is stuck in unconfirmed transactions. You can see it here: http://bitcoincharts.com/bitcoin/txlist/#c03ee2d96ef5e570bafb9a5d4d796843c89d17ee8f11e235cee715e935e0b1cf

They have been stuck there for almost a whole day. What do i do?

[1715318517]

1715318517

[1715318517]

1715318517

[1715318517]

1715318517

[1715318517]

1715318517

[cptmooseinc]

Install pywallet (it's tricky to get working if you have a super low amount of technical skill, otherwise just follow the directions). Use the web server from pywallet to wipe ALL transactions from your wallet.dat file (make sure to make a backup/copy of your wallet first in case you f*** it up, but it's hard to do). Launch Bitcoin from the command prompt with the -rescan flag beside it. No need to delete the blockchain, so don't do that!

Search the board for Pywallet and it should have links to downloads along with how to remove 0/unconfirmed transactions. I also had created a thread about needing help before because this happened to me. It will restore all your BTC back to the sending address and you can try to send it again. Looks like a lot of inputs, so you probably paid too low of a Tx fee and many nodes are ignoring it.

[Stephen Gornick]

Yesterday I made a new wallet and sent all my coins to it but they never showed up.

Your transfer transaction consolidated a bunch of "dust" transactions

I looked in on bitcoincharts and saw that it is stuck in unconfirmed transactions.

BitcoinCharts shows it as:
"This is a low priority transaction. This transaction includes 0.00600000 BTC as fee. size: 10881 bytes priority: 12,044,794 input: 9.79264834 BTC"

i.e., you submitted a large sized transaction that isn't even getting relayed it appears.

Over time it will eventually get processed (if it does not involve any double spends).  It may take a day, or so -- maybe longer since it appears some peers aren't even relaying it (evidenced by blockchain.info not even knowing about the transaction.)

If you are using Bitcoin-Qt, you can use "-connect=173.242.112.53" to have your client connect to a node that will re-broadcast your transaction regardless of the amount of fee paid.

The Bitcoin-Qt client generally won't let you make a transaction using unconfirmed funds but if you were using a different client that is something that could have happened.    What client were you using when you made the transfer?

[taltamir]

I thought bitcoing was p2p ... so who is it that is processing transactions (and delaying the processing of low payment transactions?).

[Mike Christ]

I thought bitcoing was p2p ... so who is it that is processing transactions (and delaying the processing of low payment transactions?).

The miners take care of validating transactions, and are compensated with the transaction fee, I believe.  Along with minting new ones.

[lightlord]

I thought bitcoing was p2p ... so who is it that is processing transactions (and delaying the processing of low payment transactions?).

No one controls the bitcoin network, if someone did it wouldn't have the value of nearly $30 today.
Lower transaction fees have lower priority in the network, this is to prevent spam, and stuff.
Hence the fee is needed for transfers. Bitcoin network is equally agreed upon everyone, Completely
decentralized, for it to change 51% of the people in the bitcoin network would have to change
to a different protocol then it would change. The people have the power, no one else.

That's the power of Bitcoins.

Say no to centralization and go decentralization by going Bitcoin.

[niko]

What client or service did you use to send these coins?

[toz]

If you're using the Satoshi client, you basically need to remove the unconfirmed transactions from your wallet so it will let you spend the coins again.

[taltamir]

Ok so its decentralized and low priority transactions take longer to process...
Is there any reason for him not to simply wait until it eventually gets processed rather?

[cptmooseinc]

If there's combined Tx in his output that is a double-spend, then he'll never get that Tx confirmed. I can't get the link to load properly now, but the first time I looked at it, he had 1 input that showed "unconfirmed". If his client was still syncing to the blockchain, and he'd also managed his wallet elsewhere (like blockchain.info), that would let him spend outputs without the bitcoin-qt client knowing they were ever gone. So if opened bitcoin-qt and it was still syncing, but showed he had X amount of BTC (when it was already spent), then it would be like attempting to double-spend. The Tx would live in limbo forever, along with all his valid, truly unspent BTC.

He must use Pywallet to wipe all the Tx info from the wallet.dat, then use the -rescan option and let the client fully sync to get his coins back to where he can send them off and be confirmed.

[cptmooseinc]

Got it to load right, so now I can reference his unconfirmed Tx sitting amongst all the other confirmed ones:

1.80442544 BTC from unconfirmed 1551173f5f1505deee0157c2ed3ea8e8a185fba527ab4d7ddd172860e3346945:0 (16KxERWjnHg3BhfpYCktGnn4JZXcrmvQU6)

The address seems to be one of the ones that's tucked secretly into the wallet.dat file, and not his main address. It also looks like that address that's holding back the Tx confirming was used to be on SDice. My guess is he lost a bunch on SDice by playing from blockchain.info, then loaded up his wallet.dat into a bitcoin-qt client and tried to send the coins away before they dropped off the client when it was fully synced.

So...now he needs to use Pywallet.

[niko]

Skis, can you let us know if this is resolved, or you need help with pywallet?

[taltamir]

If there's combined Tx in his output that is a double-spend, then he'll never get that Tx confirmed. I can't get the link to load properly now, but the first time I looked at it, he had 1 input that showed "unconfirmed". If his client was still syncing to the blockchain, and he'd also managed his wallet elsewhere (like blockchain.info), that would let him spend outputs without the bitcoin-qt client knowing they were ever gone. So if opened bitcoin-qt and it was still syncing, but showed he had X amount of BTC (when it was already spent), then it would be like attempting to double-spend. The Tx would live in limbo forever, along with all his valid, truly unspent BTC.

He must use Pywallet to wipe all the Tx info from the wallet.dat, then use the -rescan option and let the client fully sync to get his coins back to where he can send them off and be confirmed.

Thanks for the explanation.
This can only become an issue if you use an external wallet then and try to double spend?

[cptmooseinc]

Yeah. Say he created a wallet in the btc-qt client, then uploaded it to Blockchain.info. Well, instead of letting blockchain.info handle the wallet from now on, he also kept allowing the btc-qt client to manage it too. Now Blockchain.info is real time and always synced up, but the btc-qt client isn't unless opened.

So if skis had 5 BTCs when he uploaded the wallet to Blockchain.info, then closed his client, waited a little bit for some blocks to be generated, spent  4BTC from the Blockchain.info wallet, then he tried opening his BTC-qt client, he would still show as having 5BTC until the client reached the block number where his 4BTC output was contained.

If his wallet is out-of-sync but those coins were already confirmed, then the client would allow him to attempt to send the whole 5BTC in a Tx. If he did this before the client reached the block where he had already spent the 4BTC, then all 5BTC would be wrapped into that new Tx from his btc-qt wallet, leaving 1 unspent BTC in limbo until he corrected the wallet using Pywallet.

As soon as he wipes his wallet with Pywallet and -rescan's it, the 1BTC balance remaining will show back up and he can move on his merry way.

[taltamir]

thanks for explaining cptmooseinc