account balance inconsistency in 0.13.1 #9078

When using Bitcoin version v0.13.99.0-86f9e3d compiled myself with libdb 5.3 on Debian Jessie, AMD64, the balances reported by listaccounts become inconsistent:

$ bitcoin-cli listaccounts | grep -v \ 0.00000000 { "": -27.58320234, "PP": 4.00584319, } $ bitcoin-cli getbalance 9.43349050

When reverting back to an older version (Bitcoin version v0.11.99.0-32520bf-dirty), the balance becomes correct again:

$ bitcoin-cli listaccounts | grep -v \ 0.00000000 { "": 5.32762789, "PP": 4.10586261, }

The sum equals my total balance.

This happens on AMD64. I tried compiling the the same version on an armv7l CPU, using approximately the same wallet (from an older backup), and the balances there are reported correctly. Either the inconsistency has shown up later, or due to using this wallet backup on the ARM for some transaction during downtime on the AMD64.

I get most of my incoming BTC to other accounts, and move them to "" when paid for.

I have rolled git back and forward in a tedious search for the exact commit causing this bug. I found that the bug is not present at 1b5118bfa0d94dbc0f3d7803c3e68626b0a694ee, but shows up at the next commit: 30c2d8c635c41149b7184ea8471121c53042444c. This is a merge of pull request #7105.

Something in pull request #7105 is causing the sum of account balances to become wrong, possibly only when it discovers outgoing wallet transactions created on a different node.

@sturles does bitcoin-cli getbalance \* 1 true show the same output as bitcoin-cli getbalance?

bitcoin-cli getbalance \* 1 true returns a lower value with the newer version (30c2d8c), and it is consistent with the sum of the account values as well. Still much lower than my real balance.

There is more weirdness, which I discovered now. bitcoin-cli listunspent 0 with the newer version lists a lot of my spent outputs, some of them multiple times, with 0 confirmations and wrong (nonexisting) txid. I can identify the spent outputs via the address and amount. The scriptPubKey may be correct as well. It lists all my real unspent outputs as well, with correct txid and number of confirmations. The sum of the unspent values from real transactions equals what getbalance reports without the argument, i.e. the real balance. The older version will only list the real unspent outputs, not any of the bogus ones.

possibly only when it discovers outgoing wallet transactions created on a different node.

Sharing a wallet between nodes is unsupported, and will definitely lead to this kind of problem, or worse. 30c2d8c changed handling of transactions that aren't in blocks, aren't in the mempool, and aren't known to be conflicted (they went from depth=-1 to depth=0); that change exposes an existing inconsistency in your wallet (transactions that should be considered conflicted weren't marked as such because wallet coins were spent from a different node). A rescan should correct the wallet inconsistencies (bitcoind -rescan; it will take a while). To prevent this kind of problem in the future, you should avoid sharing your wallet between bitcoin-core instances; you can transfer funds from one node to another with ordinary transactions. I also recommend finding an alternative to the built-in accounting system; it has been deprecated for some time and will be removed.

I also recommend finding an alternative to the built-in accounting system

Do you have any recommendations of suitable replacements that are aware of chain reorgs etc.?

@dooglus I don't know the other options, I just know that bitcoin-core doesn't have an accounting system appropriate for tracking other people's "balances". I don't think there's any software for that available off-the-shelf. Businesses that need to hold balances as a core part of the service might consider developing appropriate software a startup cost. Hopefully someone who does so will open-source the product. Handling multi-party accounting for bitcoin transactions safely is a project unto itself, but that's why it isn't part of the scope of bitcoin-core.

@sturles Did rescanning fix the wallet inconsistency?

@kazcw I don't think people are asking for core to track people's "balances". I just want to know when there is a deposit to people's deposit addresses with a certain number of confirmations, and if that deposit is later reorged out of the chain, I want to know about it.

That's what the accounting system does for me currently, and I don't know how I would do it if accounting was to be removed.

I use 'listaccounts' to tell me when there's a new deposit. Any 'account' that shows up as non-zero has a new deposit. I then 'move' that amount to the default account and process the deposit in my application (which tracks the balance).

So rather than thinking that people are looking for an accounting system, what if we were just wanting to know when a deposit arrived, and when it disappeared again due to a reorg? That's all I need. Will it be possible if the accounting code is deleted?

@dooglus I think the plan is to (eventually) replace the "account balance" concept with simple address labels -- the subset of functionality that will be kept sounds like what you're describing using. This bug report relates to the current accounting system's attempts to do more than that, which is what I meant that I don't recommend relying on.

@sturles the accounts system is deprecated... pleaseeee stop using it

A rescan fixed it. @pstratem the API currently forces the account system to be used. I use sendmany a lot, which requires an account to send from as the first argument. Therefore I can't stop using it.