RPC getbalance call considers unconfirmed change to be confirmed #2276

When I run:

bitcoind getbalance '*' 1

I expect to see the sum of all the inputs in my wallet with at least 1 confirmation. The 1 is the 'minconf' parameter.

But the figure returned also includes unconfirmed change inputs.

When I specify minconf to be 1, it seems only right to sum inputs with a minimum of 1 confirmation, and no unconfirmed inputs at all.

The following change gives the result I expect in this case, but doesn't change anything if the first parameter is anything other than '*':

/* ------------------------------------------------------------------------
diff --git a/src/rpcwallet.cpp b/src/rpcwallet.cpp
index 90a68f5..d069467 100644
--- a/src/rpcwallet.cpp
+++ b/src/rpcwallet.cpp
@@ -527,19 +527,8 @@ Value getbalance(const Array& params, bool fHelp)
             if (!wtx.IsFinal())
                 continue;

-            int64 allFee;
-            string strSentAccount;
-            list<pair<CTxDestination, int64> > listReceived;
-            list<pair<CTxDestination, int64> > listSent;
-            wtx.GetAmounts(listReceived, listSent, allFee, strSentAccount);
             if (wtx.GetDepthInMainChain() >= nMinDepth)
-            {
-                BOOST_FOREACH(const PAIRTYPE(CTxDestination,int64)& r, listReceived)
-                    nBalance += r.second;
-            }
-            BOOST_FOREACH(const PAIRTYPE(CTxDestination,int64)& r, listSent)
-                nBalance -= r.second;
-            nBalance -= allFee;
+                nBalance += wtx.GetAvailableCredit();
         }
         return  ValueFromAmount(nBalance);
     }
 * ------------------------------------------------------------------------ */

Change is supposed to be invisible to the end-user, so I'd expect it to be using the ancestor transaction's confirmation count...

The problem is that the client is telling me my "balance" and how much is "unconfirmed", but the "unconfirmed" amount isn't accurate. It only counts unconfirmed coins from others, not change from myself. The "overview" tab in the Qt client makes the same mistake as the RPC getbalance call.

So it looks like I have large amounts of confirmed coins, and can afford to make a payment with confirmed coins only when in fact I can't.

If I want to wait until I have enough confirmed coins in my wallet make a payment with inputs that are in the blockchain already, I have no way of knowing how long to wait, because the wallet lies to me about my unconfirmed balance (unless I use 'bitcoind listunspent 1' and sum up the amounts myself, which is the workaround I ended up using).

Sounds like you're trying to guess what transaction fees will be added. Changing this won't help you much there, though, as there's still too many other factors (including randomness) involved... #1645 is probably more in line with what you want?

No, I don't care about transaction fees.

I was trying to place a bet on satoshidice and have it be processed immediately. They won't process a bet immediately if its inputs are unconfirmed, and I can't tell by looking at my wallet's statement of my "unconfirmed" balance what my unconfirmed balance is...

Like I say, I found a way around this by summing the outputs of 'listunspent 1', but it's still a bad thing that the wallet lies about how much of your balance is unconfirmed.

The code assumes that you would never double-spend yourself, so it assumes that change outputs WILL be confirmed and are always safe to spend.

It didn't used to, but users complained because they'd do something like: Receive 5 BTC a couple of days ago Spend 2 BTC. Then try to spend 1 BTC and get a failure

I'm not saying this patch is correct-- I'll have to think about that some more (and what getbalance '*' 1 should mean) when I have time.

I can see that it's safe for me to spend unconfirmed coins that represent my change. But others don't know that it's my change, so when I send unconfirmed change to them, they might not trust that it will ever confirm.

I want to be able to find out how much "trustworthy" funds I have, so I know whether I have enough to make a payment the recipient can trust.

I agree that the wallet should know that my unconfirmed change is safe for me to spend, but it shouldn't claim that change is confirmed when it isn't.

I don't think the user interface should be made worse just to make it easier for you to enable a DDoS against Bitcoin.

I think that having the interface show a correct value for my unconfirmed funds instead of the current incorrect value would make it better not worse.

Misleading the wallet's user into believing that he's spending confirmed funds when in reality they're unconfirmed isn't the right thing to do.

I'd support displaying an "Change needing confirmation:" .. but having the balance diminish by >X when you send X would be confusing and would rightly create anger and fear in response.

Actually I can never remember whether the Qt GUI's overview tab is telling me "balance X of which Y is unconfirmed" or "balance X plus Y more which is unconfirmed".

If it showed "Total Balance", then a gap, and then a breakdown into: "Confirmed", "Unconfirmed Change", and "Unconfirmed Deposits" it would be less ambiguous and more correct.

"Confirmed" is a very subjective measurement. For transactions from others (untrusted parties), it means they're buried 6 blocks deep. For your own (a trusted party), there is no reason to think it would be unconfirmed even before mining.

Closing this (works as intended)