I broke my wallet, sends never confirm now.

Nothing I send gets confirmed now. 

Here's how I did it:

I was sending out payments under .01 in size and not paying a transaction fee, which of course were never confirmed.

Here's a guess as to why it broke my wallet:

Because the change leftover was also then never confirmed, yet my client treats it as if it was so includes those amounts in the amounts it sends out.



I've only lost 100btc, so I'm not real worried, but if you know how to fix it without too much trouble, that'd be nice.

This seems likely. Try sending a ton of 0.01 transactions -- most of these transactions will work if this is the case.


For this you'll want to use the -maxconnections switch with a high number of connections, because propagation of your invalid transaction will be very poor.

You could also "double-spend" your pre-experiment coins by acting as though the unconfirmed transactions never happened. A wallet backup would roll things back, for example.

Hmm; I'm not sure about this case. They're not working on your new transaction because the previous transaction wasn't in a previous block and isn't in their memory pool. I don't know if they'd relay it.

They will get confirmed when someone that doesn't require fees include them in his/her block.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.You can also send the same 1BTC back and forth between two clients, using different addresses every time. If you do it fast enough you will probably be able to fill up the block that everyone is trying to generate and therefore make the network really slow and lower the chances for legitimate transactions to get into blocks... Also if you do it reeeealllly fast you could saturate the network for a long time, even after you exit the network. You will just leave the rest trying to fit hundreds of thousands of transactions into blocks... I don't know if there is any protection in the protocol from this kind of attacks... If not, they are quite easy to be done. We really need fixed transaction fees with the option to change your preferences on what is the fixed price you accept and what fee to include in your own transactions.

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.


yes but the problem is that the client doesn't let the user choose which coins to spend, it does it all "automagically" behind the scenes. so how would a user know if he's sending confirmed coins or unconfirmed coins?


yes, but that's a separate issue. i'm really trying to figure out what, if anything, to be doing about the handful of never-to-be-confirmed transactions i have in my wallet, whether the client will prioritize sending other coins first or not, and if not... that means it's possible that i'll never be able to make a send transaction that will be confirmed, because the unconfirmed bits of coin will be included. which would in turn mean that my whole wallet is foobar.

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

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.

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

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...

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

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;

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?