Topic: I broke my wallet, sends never confirm now. (Read 12660 times)

That's going to be more of a SelectCoins thing.

SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent.  This is needed because you should be able to spend your own change right away.

The new recursive determination is: 0/unconfirmed can be spent if it's yours and all its dependencies are either in a block or also yours.

Here's a Windows build:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe

This version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it.  If you were the original creator of a 0/unconfirmed transaction, you still need theymos' patch instead.

So in .13 1 confirm is good enough to pay someone with, but it takes 6 to display "confirmed" in the GUI.   This is inconsistant.  This coin is good enough to pay you with but not good enough for me to accept?  I don't know the logic behind the 6, but whatever it is, if its only used to decide which word to display, then is it really  representing anything at all?

0.3.13 release candidate, please test:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe

As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation.  0/unconfirmed transactions are very much second class citizens.  At most, they are advice that something has been received, but counting them as balance or spending them is premature.

I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending.  This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.

I didn't make it (+1.23) because parenthesis in accounting means negative.  I hope square brackets is different enough to be clear what is meant.

The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.

I uploaded the changes to SVN rev 158.  I will post a 0.3.13 RC shortly.

If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.

If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.

change:
    if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)
        continue;
to:
    if (pcoin->GetDepthInMainChain() < 1)
        continue;

ok, so i built a modified bitcoind, with the addition of 'pcoin->GetDepthInMainChain() < 1' to both SelectCoins and GetBalance.

My 'stock client' balance shows as 131.00139787, and my modified client balance shows as 130.92112098, so i have about 0.08xx of "bad" bitcoins' worth of transactions in my wallet.

So I guess now, all i need to do is create another wallet, and then send all the "good coins" from my old wallet to my new one (or, i guess... i could just use the same wallet, since my bitcoind won't try to send the bad coins, i can just ignore them....)

But yes, I hope the modifications as described by jgarzik (being configurable with cli switches/checkboxes) do make it into mainline - because otherwise it's too easy to 'poison' people's wallets with bogus transactions.

Well, I would rather split "balance" in two:  confirmed and unconfirmed balances.

Some people might want to add the

pcoin->GetDepthInMainChain() < 1

in GetBalance() too.

thanks theymos for the patch!

i guess now i have to figure out how to build bitcoind....

or maybe i'll just wait around for this to make it into the next official release...
if satoshi agrees with jgarzik as far as including those options in mainline, maybe i don't have to wait that long...

I really don't care about extremelly fast transactions. It would be enough for me if Bitcoin didn't even show unconfirmed transactions and didn't even try to spend them before they get confirmed. FFS just wait 10minutes for a block to appear confirming them. 

The best option might be four passes at 120, 6, 1, and 0, to somewhat prioritize based on depth.

IMO, this should make it into the upstream bitcoin client, as either

• a command line switch, requiring confirmation for all sent coins
• a two-pass search:  search first for confirmed coins.  if not enough confirmed coins are available, use unconfirmed coins.

At (roughly) line 3191 in main.cpp (SelectCoins), change the if statement to this:

Your client will then no longer consider coins with 0 confirmations when choosing coins.

theymos: well... the problem is that it causes problems for the wallets that happen to have received those transactions. my wallet now includes a bunch of small transactions that will never be confirmed (due to their not having paid the requisite fees).

since the client does not let the user control which coins to send, any transaction i send out in the future is liable to try to include those coins in the outgoing payment, which, in turn, will never get confirmed, thus borking my whole wallet.

so say a 'rogue' client harvests a bunch of addresses of the net (these forums are a good and ripe place), and starts sending out a bunch of .000001 payments with no fee. now these wallets will all be contaminated with these never-to-be-confirmed payments, and since the client doesn't allow one to choose which coins get sent, they may be included in future outgoing payments, which will also never get confirmed.

so what should i do to 'clear' my wallet? i'd need some custom tool to be able to send /specific coins/, so that i can send them all to another wallet and drop the contaminated one.

and more importantly, for the future - how do we address this problem?

And in the future node could certainly drop connections from nodes that generate bad transactions.

I checked the code. It seems that the transactions will be relayed, since they pass AcceptToMemoryPool. The network will tend to forget these transactions because the memory pool is cleared when Bitcoin shuts down, and as far as I can tell nodes never relay transactions that they already have in their memory pool.


There is. The more transactions waiting to be included in a block, the higher the transaction fee has to be for one to get in.

yes and.... at this point /all/ clients require fees for transactions <0.01, do you have any reason to expect that this will change at any point in the future? i don't. so "never will get confirmed" seems a reasonable approximation to reality.

There is no invalid chain just because someone didn't want to pay the fee. It will just take longer for them to get included in a block and until then they can be double spend if someone hasn't heard about them. BTW if nodes don't propagate transactions just because they don't like them it will be dangerous since it will be easier for someone to double spend bitcoins.