If you really need to override this behavior, you should be able to use the raw transaction API.
Also, the client won't include generated coins in the balance or new transactions until 120 blocks have passed. I just mention it for completeness.
Topic: RPC "GetBalance" when does it increment? (Read 1100 times)
So that leads me to my followup question. It isn't possible to "spend" 0-confirm tx with bitcoind? The protocol allows it.
0-confirm transactions can only be spent if they came from yourself (change or send-to-self), since bitcoind doesn't "trust" transactions from other sources until they have at least 1 confirmation. This rule came about after one version of Bitcoin had a bug that caused it to sometimes send transactions with insufficient fees, which would therefore never be confirmed. Normally this would be no big deal, except that other clients simply accepted these transactions and spent them, creating even more transactions which would never confirm, which would be spent again, and so on ad infinitum, until finally everyone's transactions were getting stuck because everyone's wallets were filled with coins that were never going to confirm. It was a real mess.So now Bitcoin will only trust other people's transactions if they have at least one confirmation, which is the way it should be. The old way of just trusting all transactions, confirmed or not, never really made sense, since the whole point of distinguishing between confirmed and unconfirmed transactions in the first place is that unconfirmed transactions can't be trusted (eg, they may yet be double-spent, while confirmed transactions cannot (at least, not without a lot of further discussion)).
There are many ways that the bitcoin software is more conservative than the protocol 
Only relaying standard transactions is another well-known example...
Only relaying standard transactions is another well-known example...
Ah. No wonder why I couldn't figure it out. I first assumed it was 0 but then I noticed a delay so I figured it was 1 but that wasn't always consistent. I didn't think of the possibility that "from self" would be handled differently.
So that leads me to my followup question. It isn't possible to "spend" 0-confirm tx with bitcoind? The protocol allows it.
If bitcoind doesn't increment until 1 confirmation it will error out (insufficient funds) until 1-confirm is detected and it it increments.
Thus bitcoind is more conservative than the protocol? I guess this behavior can't be overriden without modifying the source.
So that leads me to my followup question. It isn't possible to "spend" 0-confirm tx with bitcoind? The protocol allows it.
If bitcoind doesn't increment until 1 confirmation it will error out (insufficient funds) until 1-confirm is detected and it it increments.
Thus bitcoind is more conservative than the protocol? I guess this behavior can't be overriden without modifying the source.
When does "GetBalance" increment?
When the bitcoind receives a 0-confirm tx, after 1 confirmation, after 6?
Can this be modified short of modifying the source code and recompiling?
When the bitcoind receives a 0-confirm tx, after 1 confirmation, after 6?
Can this be modified short of modifying the source code and recompiling?
Had to ask sipa for the answer: 1 for external transactions, 0 for change or send-to-self ones
When does "GetBalance" increment?
When the bitcoind receives a 0-confirm tx, after 1 confirmation, after 6?
Can this be modified short of modifying the source code and recompiling?
When the bitcoind receives a 0-confirm tx, after 1 confirmation, after 6?
Can this be modified short of modifying the source code and recompiling?
Jump to: