HELP! Transactions not confirming ;( - 4 btc bounty

[caveden]

Well, the easiest solution at this point would be to revert to a recent backup of your wallet (you have one, right?) and double-spend these coins by sending the entire contents of the wallet to another of your addresses.

If I do this will it mess up the 120 or so transactions I've done since the corrupted transactions?

If the backup contains all the private keys, a rescan should be enough for it to see transactions that were confirmed. It will see them in the chain.
What's important is that the backup contain all private keys, but not all transactions.
Keep a copy of your current wallet before doing this, of course.

[1715051733]

1715051733

[1715051733]

1715051733

[1715051733]

1715051733

[caveden]

why don't you ask your angry customers to provide details on the transactions they did?

I thought these transactions were initiated by Jeremy's wallet...
If they are incoming transactions then the problem is not with him, but with those trying to send the money.

[Jeremy West spendbitcoins.com]

Note:

I searched for the 5 transactions you reported in the debug.log of my Electrum server  (it is always up).
My server has not seen these transactions; I guess they were not propagated by the network.
It could be a double spend attack, or a problem with the bitcoin client used by your customers.

why don't you ask your angry customers to provide details on the transactions they did?
are they really 5 separate customers?

These are transactions FROM me not TO me. And I am aware from bitcoincharts.com that they are not even on the network as unconfirmed. However, even with a rescan they are no longer showing in my balance.

[Jeremy West spendbitcoins.com]

Well, the easiest solution at this point would be to revert to a recent backup of your wallet (you have one, right?) and double-spend these coins by sending the entire contents of the wallet to another of your addresses.

If I do this will it mess up the 120 or so transactions I've done since the corrupted transactions?

If the backup contains all the private keys, a rescan should be enough for it to see transactions that were confirmed. It will see them in the chain.
What's important is that the backup contain all private keys, but not all transactions.
Keep a copy of your current wallet before doing this, of course.

Good point. I'll try this. Thanks!

[ThomasV]

Note:

I searched for the 5 transactions you reported in the debug.log of my Electrum server  (it is always up).
My server has not seen these transactions; I guess they were not propagated by the network.
It could be a double spend attack, or a problem with the bitcoin client used by your customers.

why don't you ask your angry customers to provide details on the transactions they did?
are they really 5 separate customers?

These are transactions FROM me not TO me. And I am aware from bitcoincharts.com that they are not even on the network as unconfirmed. However, even with a rescan they are no longer showing in my balance.

sorry for the confusion :-)
it looks like they were rejected by the network.
check your own debug.log to see the cause (probably a blockchain reorg).

[Bitcoin Oz]

Maybe you are the victim of a doublespend ?

[Jeremy West spendbitcoins.com]

Note:

I searched for the 5 transactions you reported in the debug.log of my Electrum server  (it is always up).
My server has not seen these transactions; I guess they were not propagated by the network.
It could be a double spend attack, or a problem with the bitcoin client used by your customers.

why don't you ask your angry customers to provide details on the transactions they did?
are they really 5 separate customers?

These are transactions FROM me not TO me. And I am aware from bitcoincharts.com that they are not even on the network as unconfirmed. However, even with a rescan they are no longer showing in my balance.

sorry for the confusion :-)
it looks like they were rejected by the network.
check your own debug.log to see the cause (probably a blockchain reorg).

What should I search for?

[notme]

Well, the easiest solution at this point would be to revert to a recent backup of your wallet (you have one, right?) and double-spend these coins by sending the entire contents of the wallet to another of your addresses.

If I do this will it mess up the 120 or so transactions I've done since the corrupted transactions?

I think the default keypool is only 100.  If you're doing this many transactions you should set the keypool size to 1500 or some other high number so your backups are at least valid for a few days.

Anyway, if over 100 of those transactions are receiving coins to new addresses (this includes any sends with change), you might lose some bitcoins.  Otherwise you should be okay with your backup.  If you've used too many addresses, I'd set up pywallet and remove the transactions from your live wallet after making a backup (without bitcoin running).

Finally, to figure out what went wrong, as ThomasV suggests, check your debug.log.  I imagine yours may be fairly dense if you are doing so many transactions.  Searching for the first 10 digits of the transaction id should get you in the right area.

[ThomasV]

Note:

I searched for the 5 transactions you reported in the debug.log of my Electrum server  (it is always up).
My server has not seen these transactions; I guess they were not propagated by the network.
It could be a double spend attack, or a problem with the bitcoin client used by your customers.

why don't you ask your angry customers to provide details on the transactions they did?
are they really 5 separate customers?

These are transactions FROM me not TO me. And I am aware from bitcoincharts.com that they are not even on the network as unconfirmed. However, even with a rescan they are no longer showing in my balance.

sorry for the confusion :-)
it looks like they were rejected by the network.
check your own debug.log to see the cause (probably a blockchain reorg).

What should I search for?

search for ERROR.
on Linux, you can use grep :  

Code:

cat debug.log | grep -10 ERROR

you should see lines that look like this:

Code:

ERROR: ConnectInputs() : 6501716a6a mapTransactions prev not found 3ad23a50d9

(with different numbers)

you can also use the first chars of the transaction hashes in the grep command:
 

Code:

cat debug.log | grep -10 ccf585

[Jeremy West spendbitcoins.com]

Sorry for the ignorance. This log means nothing to me. Can anyone find anything in here that would tell me what to do?

https://www.dropbox.com/s/o9cq3u68emdt4hb/debug.log

[CIYAM]

I found the following in your debug.log:

Done loading
mapBlockIndex.size() = 183184
nBestHeight = 183183
setKeyPool.size() = 100
mapWallet.size() = 1777
mapAddressBook.size() = 1119
addUnchecked(): size 0
CTxMemPool::accept() : accepted ccf585bcfe
addUnchecked(): size 1
CTxMemPool::accept() : accepted ee188b9e04
addUnchecked(): size 2
CTxMemPool::accept() : accepted b1f331143f
addUnchecked(): size 3
CTxMemPool::accept() : accepted 11fd5b6aed
addUnchecked(): size 4
CTxMemPool::accept() : accepted 4b87953acc
Bound to port 8333
06/05/12 22:24 RandAddSeed() 212612 bytes
addrLocalHost = 58.106.25.78:8333

Not sure exactly what that tells us but those are the starting characters of your 5 tx's.

Also found this:

ResendWalletTransactions()
Relaying wtx ccf585bcfe
Relaying wtx ee188b9e04
Relaying wtx b1f331143f
Relaying wtx 11fd5b6aed
Relaying wtx 4b87953acc
received getdata for: tx ccf585bcfed1283d11b5
received getdata for: tx ee188b9e048d4889d7ad
received getdata for: tx b1f331143fbf75f0e8ce
received getdata for: tx 11fd5b6aed10e545136a
received getdata for: tx 4b87953accada36255e8
received getdata for: tx ccf585bcfed1283d11b5
received getdata for: tx ee188b9e048d4889d7ad
received getdata for: tx b1f331143fbf75f0e8ce
received getdata for: tx 11fd5b6aed10e545136a
received getdata for: tx 4b87953accada36255e8

The above actually appears a number of times (so I guess it kept trying to resend these tx's unsuccessfully).

[Jeremy West spendbitcoins.com]

Currently trying Maged's idea of restoring a backup bitcoin folder. Less than 2 days behind, should be up to date soon and know whether I'm all sorted.

[Jeremy West spendbitcoins.com]

Currently trying Maged's idea of restoring a backup bitcoin folder. Less than 2 days behind, should be up to date soon and know whether I'm all sorted.

Damn it! Ended up with the same 5 unconfirmed transactions! Why would that be if they never ended up on the network?

[CIYAM]

Damn it! Ended up with the same 5 unconfirmed transactions! Why would that be if they never ended up on the network?

I think the problem is that the tx's are known to your wallet so will just keep coming back.

Otherwise, you can set-up pywallet and delete the individual transactions from your wallet. It's easy to do this, luckily, but setup is a pain (lots of sitting and clicking until everything is installed).

Perhaps you will need to do this (and note that there is a Windows version of the tool).

[caveden]

Currently trying Maged's idea of restoring a backup bitcoin folder. Less than 2 days behind, should be up to date soon and know whether I'm all sorted.

Damn it! Ended up with the same 5 unconfirmed transactions! Why would that be if they never ended up on the network?

The backup you used was done after the 5 bogus transactions. For that to work, you'd need to find a backup which was done before the bogus transactions, but which happens to contains all your private keys. Seeing the number of transactions you make, that might be difficult. 
You'll probably have to resort to manually deleting the transactions...


To the devs: isn't this a bug in the Satoshi client? Shouldn't the client try to rebroadcast unconfirmed transactions once in a while? If it does rebroadcast, just not fast enough for Jeremy's needs, then isn't this an enhancement issue that should be logged anyway? (allowing the user to configure the rebroadcasting periods, and/or adding a command line switch (perhaps even GUI) to manually force the rebroadcast...)

Or is there something peculiar with those transactions that make them be refused by everyone every time they are sent? I'm ruling out voluntary double-spends. (if it's an involuntary one, it's possibly an even more serious issue...)

[dooglus]

I think that using Gavin's bitcointools to mark the 5 rogue transactions as 'unspent' should fix your problem.

Get it from here:
  https://github.com/gavinandresen/bitcointools

Then something like:
  python fixwallet.py --tweakspent ccf585bcfed1283d11b5012c5f3f3429c5695a8d2280287c44e605223b6318b5

I'll experiment here to see if it works, and report back.

[dooglus]

To the devs: isn't this a bug in the Satoshi client? Shouldn't the client try to rebroadcast unconfirmed transactions once in a while? If it does rebroadcast, just not fast enough for Jeremy's needs, then isn't this an enhancement issue that should be logged anyway? (allowing the user to configure the rebroadcasting periods, and/or adding a command line switch (perhaps even GUI) to manually force the rebroadcast...)

Or is there something peculiar with those transactions that make them be refused by everyone every time they are sent? I'm ruling out voluntary double-spends. (if it's an involuntary one, it's possibly an even more serious issue...)

It is rebroadcasting the transactions over and over.  From the log Jeremy put on dropbox:

Code:

ResendWalletTransactions()
Relaying wtx ccf585bcfe
Relaying wtx ee188b9e04
Relaying wtx b1f331143f
Relaying wtx 11fd5b6aed
Relaying wtx 4b87953acc

I'm wondering if the transactions are invalid for some reason, and so his peers aren't accepting the transactions.  I don't know why that would be though.

[Jeremy West spendbitcoins.com]

Currently trying Maged's idea of restoring a backup bitcoin folder. Less than 2 days behind, should be up to date soon and know whether I'm all sorted.

Damn it! Ended up with the same 5 unconfirmed transactions! Why would that be if they never ended up on the network?

The backup you used was done after the 5 bogus transactions. For that to work, you'd need to find a backup which was done before the bogus transactions, but which happens to contains all your private keys. Seeing the number of transactions you make, that might be difficult. 
You'll probably have to resort to manually deleting the transactions...

I used my current wallet with a backup of all the rest of the files in the bitcoin folder from 1 day prior to the unconfirmed transactions. My understanding was that the wallet contained nothing but the private keys. Is this incorrect?

[Bitcoin Oz]

To the devs: isn't this a bug in the Satoshi client? Shouldn't the client try to rebroadcast unconfirmed transactions once in a while? If it does rebroadcast, just not fast enough for Jeremy's needs, then isn't this an enhancement issue that should be logged anyway? (allowing the user to configure the rebroadcasting periods, and/or adding a command line switch (perhaps even GUI) to manually force the rebroadcast...)

Or is there something peculiar with those transactions that make them be refused by everyone every time they are sent? I'm ruling out voluntary double-spends. (if it's an involuntary one, it's possibly an even more serious issue...)

It is rebroadcasting the transactions over and over.  From the log Jeremy put on dropbox:

Code:

ResendWalletTransactions()
Relaying wtx ccf585bcfe
Relaying wtx ee188b9e04
Relaying wtx b1f331143f
Relaying wtx 11fd5b6aed
Relaying wtx 4b87953acc

I'm wondering if the transactions are invalid for some reason, and so his peers aren't accepting the transactions.  I don't know why that would be though.

Could someone isolate his node and refuse transactions ?

[CIYAM]

My understanding was that the wallet contained nothing but the private keys. Is this incorrect?

Unfortunately it contains a lot more than just the private keys which I guess is exactly why the pywallet tool was created.