Wallet lost track of funds #9620

bitcoin-cli getbalance

is currently showing 0.75593999, while in reality the wallet has a lot more than that

I tracked some of my money to this change address: https://tradeblock.com/bitcoin/address/19pozzqPQ6tmubTPGY5KXy3GR5agAaAedA

Which currently has 66.5 BTC in it (but it's not confirmed)

It seems that bitcoin core was forced to spend from an unconfirmed change (which was in its balance) and the unconfirmed change of unconfirmed change is not showing up as in my balance?

Other than giving me a bit of a scare, this is a bit of an issue as I can't spend the money (which I'd like to do) which would also have the nice side effect of helping to prioritize the unconf chain as the estimatefee has gone up since that was created

Just to clarify: that address is yours (ie no money was lost, only isnt being displayed by a normal "getbalance" rpc call (ie getunconfirmedbalance is correct)?

The money isn't showing in either getunconfirmedbalance or getbalance. I'll let you know what happens after it confirms, but I strongly suspect it'll arrive back in my (visible) wallet. I have the private key for the address it's in (I double checked that :P), so there's absolutely no risk in that sense.

I've never had a problem with the wallet and unconfirmed change, but it seems to have been triggered by the spending of spending unconfirmed change, if I had to guess.

But my big concern is, what would happen if the transaction chain never confirmed? Seems like it's possible someone could "lose" money this way

Also interestingly the problem is currently still showing, but there is now only a single unconfirmed transaction:

f600e0a64f2166deb03804499c09e1b3c07636a2d5725f4a10852774da02dd8a

which has most of my money going to a change address (whose balance is not currently being shown by either getbalance or getunconfirmedbalance).

At the time that transaction was created, it was sourcing an unconfirmed transaction, which I think (but not sure) was sourcing some unconfirmed transactions.

I assume you are running 0.13.2, right?

Yeah. Also the problem is much worse than I thought, that transaction has confirmed and the funds are no where to be seen.

$ bitcoin-cli listunspent 0 | grep f600e0a64f2166deb03804499c09e1b3c07636a2d5725f4a10852774da02dd8a

return nothing as well. However, that change address is actually in my wallet.

Well the good news is that I ran bitcoind -rescan and it found my money =)

Can you elaborate on what kinds of action you've done with this wallet? (RPCs, GUI operations, copying files around...). Balances disappearing is very serious, and we should figure out what caused this.

I don't have the gui installed, so I don't do anything weird with that. I only interact with it over rpc, 99% of the time itor do anything weird. But I use it as a backend for my service and it gets hit by a lot of rpc calls to sendtoaddress.

As far as I know, this is the first time it's ever really been forced to spend from a chain of unconfirmed transactions -- so I believe this is what must have triggered it.

Not sure if it matters, but the wallet itself is a few years old (so it's non-hd) and I have txindex=1 set

I'm also using totally default settings regarding spending unconfirmed funds.

I suspect it's related to this transaction: 702a1bfe235405069e50340c10e0b8236e25124ab5bab89a87ab3859a4f97f3b

Which was generated via rpc sendtoaddress 1JyZ2dJq2tz6RDTuNQfwg498Qu2CoCp7TG 66.6 where the interesting thing is that 1JyZ2dJq2tz6RDTuNQfwg498Qu2CoCp7TG is actually part of my wallet. It's also worth noting that in order to create that transaction, it needed to source a bunch of unconfirmed transactions itself.

The next transaction was generated via rpc sendtoaddress 1GUJWXTG9bCL72G2nPjEaWpSLC9FG5vfF2 0.0997 actually sourced that unconfirmed money from the "main" output of 702a1bfe235405069e50340c10e0b8236e25124ab5bab89a87ab3859a4f97f3b (I guess because it trusts it, because it comes from me, even though it's not a change output?).

And it was the change from that send (that arrived in 19pozzqPQ6tmubTPGY5KXy3GR5agAaAedA) which appeared to have been permanently lost until I rescanned the wallet.

It also seems like a pretty rare case. My wallet has made 126,591 sends and this appears to be the only case of it. I was kind of hoping it happened more often, and found all these lost riches after I did the rescan :(

I know you've already said this, but to just be 100% explicit, which getbalance call were you using?

getbalance ?

not getbalance '*' or getbalance ''?

Yeah, I was using just normal bitcoin-cli getbalance. The actual reason I noticed was that my site couldn't process any more withdrawals, even though the wallet should've had lots of funds in it. (I don't programmatically query the balance, I just blindly fire off sendtoaddress rpc requests)

When doing bitcoin-cli listunspent 0 it also didn't show the output, both before and after the transaction had confirmed. (Although after the -rescan, it did)

Could you check your debug.log for AddToWallet f600e0a64f2166deb03804499c09e1b3c07636a2d5725f4a10852774da02dd8a?

It should have appeared when you placed the transaction, again when that transaction was confirmed in a block, and again when you did the rescan and it got to that block.

$ cat ~/.bitcoin/debug.log | grep f600e0a64f2166deb03804499c09e1b3c07636a2d5725f4a10852774da02dd8a

Only returns one entry:

2017-01-24 15:21:24 AddToWallet f600e0a64f2166deb03804499c09e1b3c07636a2d5725f4a10852774da02dd8a

from the time of rescanning.

Although the first entry I see in my ~/.bitcoin/debug.log is very recent: 2017-01-24 13:38:51 receive version message: /Bither1.6.0/: version 70001, blocks=449795, us=127.0.0.1:8333, peer=625536

Seems like it's automatically truncated?

This however is quite interesting:

$ cat ~/.bitcoin/debug.log | grep 702a1bfe235405069e50340c10e0b8236e25124ab5bab89a87ab3859a4f97f3b
2017-01-24 15:21:23 AddToWallet 702a1bfe235405069e50340c10e0b8236e25124ab5bab89a87ab3859a4f97f3b  
2017-01-24 15:21:23 Transaction e1a732892538809478e344bf47c513e41c5dc0eb33fd38d8d54695c79b3d9796 (in block 00000000000000000165a1a4b244278015d3d538d503609f2301199a7a3cea72) conflicts with wallet transaction 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c (both spend 702a1bfe235405069e50340c10e0b8236e25124ab5bab89a87ab3859a4f97f3b:1)

So transaction e1a732892538809478e344bf47c513e41c5dc0eb33fd38d8d54695c79b3d9796 on the blockchain is a quick-and-dirty transaction I created (manually) and broadcasted myself to do some CPFP action. While doing that, it seems to have conflicted with a transaction my wallet generated: 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c whose contents are:

010000000488083f430529034ff9418ff04b612bef176d327de22f3bb7e6625d2235587e5e000000006b483045022100f149050241f1fb1f54550471adf1affcd57e4cbb36e4148574a29a457f78687402200be84b23455077c9b9dac326c6017ea12d471ff63b4e6e8d07bdd63e3304d4b7012103b0af308aa07c4dbdb5ac7997588ba65335a103914aa2e390100d3bfa8d3da2aafeffffff887326bd759dee8a863767a03851c3edfc099dc9909c602d159a32de77e563fd000000006946304302206383b94705c164ffab60b7e24b27934d05cef017d8a607c553cb5e963ac1379b021f21d405918a8b7655f6ff3da6f37a34cdcf128678cd886c2b353352e10c6d3e012102cd3a1be957907775d65ef28cf57dd4cede822a50ac2dca03941f3565e22ef848feffffffb23889605c2ba89b378374e0e3a59326829e43448bfe75d68e91640c74b9d8ce010000006b483045022100955b7904ba49c12a32b832fd8a56bb92697c621d02003ccb0a8b46ff5455527f02200450eebfe6ff50e10e29cdf7d4a95da2e0547001233b70d97f1be3efa0d82d5c0121031ba7139f7c39f37f4c352c8b5cc25348e55cb7239e9a9b1fc1b4218e4970345dfeffffff3b7ff9a45938ab879ab8bab54a12256e23b8e0100c34509e06055423fe1b2a70010000006a473044022038d0d9d6bbe27a752130021efe6dfe72ab8da8818668f98a1d6086210cdc1f5f02207f9658ad2bb99d3bbf7e5854a1fdb986b55b9cdbd9fe35a959ff9e1f88fd811401210210b958b5f9c4c0ce64e0e03afb96d7eae2d53d4a534daf174ed8de766afc26e0feffffff02eb2e0000000000001976a9144a1e7cf8cee728aa3cacca6a4e02f5bafc9d3f6d88acd05e3000000000001976a9149925601955f59f337a20b752c2e93225683e878a88aca8dc0600

It seems quite possible this was somehow involved in me losing funds

It's a shame I don't have better logs for it, when I excecuted the RPC command sendtoaddress 1ExmAEmkdQcMxHQW7a37TojVR7hxhaaxSK 0.0317 my application logged it as failing (although unfortunately I didn't log the exact error lol).

However, there's a wallet transaction above that was generated (117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c) for it. However, none of the block explorers seem to have ever seen that transaction, so it was likely never pushed onto the network. (probably cause of the conflicting manual CPFP transaction i made: e1a732892538809478e344bf47c513e41c5dc0eb33fd38d8d54695c79b3d9796 )

your debug log doesn't include the times when you actually placed the transactions right? I saw them relayed around 2017-01-23 23:27:43, does your log have anything from that time period?

Nope :(

The earliest entry in my ~/.bitcoin/debug.log is from 2017-01-24 13:38:51. I'm not sure why that is, I certainly didn't manually clear it or anything

The debug.log file gets shrunk on restart. See #9625.

I'm having trouble knowing where to look next for what might have caused this problem.

• Were there any other manual double spends or other manual transactions that you created?
• I assume you had -spendzeroconfchange set to true (the default)?
• Did you abandon any transactions?
• Were any of these transactions "mixed-debit", that is spent some of your inputs and some of somebody elses?
• Do you know if the transaction was in your node's mempool?

With the information you've given, I can't see why your wallet wouldn't have recognized the output of f600e0a64f2166deb03804499c09e1b3c07636a2d5725f4a10852774da02dd8a as your money.

If this happens again (hopefully not), then please make a copy of the debug.log before restarting your node.

Were there any other manual double spends or other manual transactions that you created?

No, e1a732892538809478e344bf47c513e41c5dc0eb33fd38d8d54695c79b3d9796 was the only transaction I have manually created in a while. It wasn't intended to be a double-spend, but to child-pays for parent. Guess I had bad luck with the timing of that.

I assume you had -spendzeroconfchange set to true (the default)?

Yeah, I'm running with default settings

Did you abandon any transactions?

No, I've never used abandon

Were any of these transactions "mixed-debit", that is spent some of your inputs and some of somebody elses?

No, all transactions (with the exception of the single CPFP) are simply created with sendtoaddress $addr $amount and all inputs are owned by me

Do you know if the transaction was in your node's mempool?

I forgot to check, but even after it confirmed it never showed up

If this happens again (hopefully not), then please make a copy of the debug.log before restarting your node.

Sure, dumb of me to not do so

@RHavar Ok I think I have an idea Can you run gettransaction 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c

I'm guessing that the 117 transaction might have spent the f60 output, causing it to appear spent, but since 117 wasn't in your mempool, you didn't see the output of that as yours.

That situation should have rectified itself when 117 was marked conflicted though, which would have happened when e1a was confirmed in block 449727? But that seems not to have happened?

bitcoin-cli gettransaction 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c

{
  "amount": -0.03170000,
  "fee": -0.00046706,
  "confirmations": -98,
  "trusted": false,
  "txid": "117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c",
  "walletconflicts": [
    "044fc10bc12fe9d195590e76242c4b9474d7ade638e69238b0fb4c3734c0e173", 
    "e1a732892538809478e344bf47c513e41c5dc0eb33fd38d8d54695c79b3d9796", 
    "5cda8994d62263c536649948d333197ff8e3e6d043b983388ac0fe5ee49b3dc2"
  ],
  "time": 1485214577,
  "timereceived": 1485214577,
  "bip125-replaceable": "unknown",
  "details": [
    {
      "account": "",
      "address": "1ExmAEmkdQcMxHQW7a37TojVR7hxhaaxSK",
      "category": "send",
      "amount": -0.03170000,
      "vout": 1,
      "fee": -0.00046706,
      "abandoned": false
    }
  ],
  "hex": "010000000488083f430529034ff9418ff04b612bef176d327de22f3bb7e6625d2235587e5e000000006b483045022100f149050241f1fb1f54550471adf1affcd57e4cbb36e4148574a29a457f78687402200be84b23455077c9b9dac326c6017ea12d471ff63b4e6e8d07bdd63e3304d4b7012103b0af308aa07c4dbdb5ac7997588ba65335a103914aa2e390100d3bfa8d3da2aafeffffff887326bd759dee8a863767a03851c3edfc099dc9909c602d159a32de77e563fd000000006946304302206383b94705c164ffab60b7e24b27934d05cef017d8a607c553cb5e963ac1379b021f21d405918a8b7655f6ff3da6f37a34cdcf128678cd886c2b353352e10c6d3e012102cd3a1be957907775d65ef28cf57dd4cede822a50ac2dca03941f3565e22ef848feffffffb23889605c2ba89b378374e0e3a59326829e43448bfe75d68e91640c74b9d8ce010000006b483045022100955b7904ba49c12a32b832fd8a56bb92697c621d02003ccb0a8b46ff5455527f02200450eebfe6ff50e10e29cdf7d4a95da2e0547001233b70d97f1be3efa0d82d5c0121031ba7139f7c39f37f4c352c8b5cc25348e55cb7239e9a9b1fc1b4218e4970345dfeffffff3b7ff9a45938ab879ab8bab54a12256e23b8e0100c34509e06055423fe1b2a70010000006a473044022038d0d9d6bbe27a752130021efe6dfe72ab8da8818668f98a1d6086210cdc1f5f02207f9658ad2bb99d3bbf7e5854a1fdb986b55b9cdbd9fe35a959ff9e1f88fd811401210210b958b5f9c4c0ce64e0e03afb96d7eae2d53d4a534daf174ed8de766afc26e0feffffff02eb2e0000000000001976a9144a1e7cf8cee728aa3cacca6a4e02f5bafc9d3f6d88acd05e3000000000001976a9149925601955f59f337a20b752c2e93225683e878a88aca8dc0600"
}

well that idea wasn't quite right, sorry.

do you know if there were any other transactions that didn't work like the 117 one?

or any other conflicts with wallet transaction in your debug.log?

There's quite a few, but none recently. Here's the tail of it:

2017-01-24 15:20:14 Transaction 4e051ad4f11de9d2d18789a1be3bd042ab580f39742322f65e4440a8e755d02a (in block 000000000000000000f3a5d13ecb2e75863b16a12f2a8505bcf5539a8c1d3a2c) conflicts with wallet transaction e5db9b3de5e8b4d6c1ab73c538629d8e159c310c2df7600f6610eabd0b643793 (both spend b3c26fca456ef4c4003b7fa34e4b629ba457be7899c33552b6240af771b81bce:100)
2017-01-24 15:21:23 Transaction e1a732892538809478e344bf47c513e41c5dc0eb33fd38d8d54695c79b3d9796 (in block 00000000000000000165a1a4b244278015d3d538d503609f2301199a7a3cea72) conflicts with wallet transaction 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c (both spend 702a1bfe235405069e50340c10e0b8236e25124ab5bab89a87ab3859a4f97f3b:1)
2017-01-24 15:21:24 Transaction 044fc10bc12fe9d195590e76242c4b9474d7ade638e69238b0fb4c3734c0e173 (in block 000000000000000001784ecbd952443a6c94880c8468dda2faf0590e6c4600fa) conflicts with wallet transaction 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c (both spend 5e7e5835225d62e6b73b2fe27d326d17ef2b614bf08f41f94f032905433f0888:0)
2017-01-24 15:21:24 Transaction 044fc10bc12fe9d195590e76242c4b9474d7ade638e69238b0fb4c3734c0e173 (in block 000000000000000001784ecbd952443a6c94880c8468dda2faf0590e6c4600fa) conflicts with wallet transaction 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c (both spend ced8b9740c64918ed675fe8b44439e822693a5e3e07483379ba82b5c608938b2:1)
2017-01-24 17:45:30 Transaction 5cda8994d62263c536649948d333197ff8e3e6d043b983388ac0fe5ee49b3dc2 (in block 0000000000000000017c5ccc3943c9e63da260d6ee059a736fb78317aee2a70d) conflicts with wallet transaction 117f591dc7e0ea1779e415d3f0d9dffe14004827fe869279d7a92723551fe53c (both spend fd63e577de329a152d609c90c99d09fcedc35138a06737868aee9d75bd267388:0)

(the first one in that tail, is from 18 days ago)

OK.. Thanks for your help with this. I'm not sure how much you want to keep answering questions, but here you go.

You said you are running 0.13.2 right? Because it's pretty unlikely for sendtoaddress to fail with 0.13.2, it is possible that the wallet txid it returns didn't get accepted to the mempool, but it doesn't look like a failure. Do you know if your application failing on 117 was a result of the return value of sendtoaddress or possibly some other logic, like looking for your tx in the mempool?

The other thing that's worth thinking about is the tx 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6 which spends that 66.5 BTC output from the f60 transaction. Can you try searching for that in your log and also do a gettransaction on it (in the off chance it has any wallet conflicts)? If you had generated that one some time ago but it had failed to be accepted to your mempool (in the same way 117 was) then it's possible it would have looked like your money was missing. But again with 0.13.2, the 6ff tx should have been continuously tried to be reaccepted to your mempool, so you should not have needed to wait for a block in order to see that money as yours again.

I'm also curious about 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6. If it somehow hadnt made it into your mempool (do you have a super small maxmempool or so?) then that would explain most of this, I'm just not clear on how that would have happened.

You said you are running 0.13.2 right? Because it's pretty unlikely for sendtoaddress to fail with 0.13.2, it is possible that the wallet txid it returns didn't get accepted to the mempool, but it doesn't look like a failure.

Yeah, I'm running 0.13.2. Unfortunately, I don't log the error, just the fact it failed. So I have no idea why it failed =/. It's even possible it took longer than usual and timed out. Send to address normally takes 5-20 seconds to return, so it could have conceivably hit the 30 second timeout.

The other thing that's worth thinking about is the tx 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6 which spends that 66.5 BTC output from the f60 transaction. Can you try searching for that in your log and also do a gettransaction on it (in the off chance it has any wallet conflicts)

cat ~/.bitcoin/debug.log | grep 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6 -A 5 -B 5

gives:

$ cat ~/.bitcoin/debug.log | grep 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6 -A 5 -B 5
2017-01-24 15:21:25 AddToWallet ffcd29a98909b49d040be27e9fb9873a5970317e75567dce3efc701b97bd5d54  
2017-01-24 15:21:25 AddToWallet ba10a850c5c674b3a13a6d1914d7c0a8e05ea2f8ce9eb7b02726b003ef83d6c1  
2017-01-24 15:21:26 AddToWallet b7c6dae15800a2f35ac7cbac854dbb95700b9654b09a3429684b071436bc21c8  
2017-01-24 15:21:26 AddToWallet e01a57d406efc73fa8737fc59e19992997f53850793b50c2856ca01d01f2cddf  
2017-01-24 15:21:26 AddToWallet 94afa233b9b924eb82d37900754770a671e6f584237fd56c0ee135c434bca94b  
2017-01-24 15:21:26 AddToWallet 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6  
2017-01-24 15:21:26 AddToWallet f43459559a1467dce61266de8c9ff24301f5d47458936f5ce297b3e570781a42  
2017-01-24 15:21:26 AddToWallet fd3b229bd87357ceb521f8657104f0954563d2d80340145a6eeb1766821b1e01  
2017-01-24 15:21:26 AddToWallet a6965943dce6112cdabe9a9e36d39f432b419054dfc893487b5224d7322b61a7  
2017-01-24 15:21:26 AddToWallet 3bc722f7b210a80efa5a8de030f64ab8ce1940a5e45801b57d9444dbbb99e67c  
2017-01-24 15:21:26 AddToWallet 46d82330d53afa5087470118cdf4cf69771aed94851bd9282f107cd383f7676c  
--
2017-01-24 15:32:09 Relaying wtx ffcd29a98909b49d040be27e9fb9873a5970317e75567dce3efc701b97bd5d54
2017-01-24 15:32:09 Relaying wtx ba10a850c5c674b3a13a6d1914d7c0a8e05ea2f8ce9eb7b02726b003ef83d6c1
2017-01-24 15:32:09 Relaying wtx b7c6dae15800a2f35ac7cbac854dbb95700b9654b09a3429684b071436bc21c8
2017-01-24 15:32:09 Relaying wtx e01a57d406efc73fa8737fc59e19992997f53850793b50c2856ca01d01f2cddf
2017-01-24 15:32:09 Relaying wtx 94afa233b9b924eb82d37900754770a671e6f584237fd56c0ee135c434bca94b
2017-01-24 15:32:09 Relaying wtx 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6
2017-01-24 15:32:09 Relaying wtx f43459559a1467dce61266de8c9ff24301f5d47458936f5ce297b3e570781a42
2017-01-24 15:32:09 Relaying wtx fd3b229bd87357ceb521f8657104f0954563d2d80340145a6eeb1766821b1e01
2017-01-24 15:32:09 Relaying wtx a6965943dce6112cdabe9a9e36d39f432b419054dfc893487b5224d7322b61a7
2017-01-24 15:32:09 Relaying wtx 3bc722f7b210a80efa5a8de030f64ab8ce1940a5e45801b57d9444dbbb99e67c
2017-01-24 15:32:09 Relaying wtx 46d82330d53afa5087470118cdf4cf69771aed94851bd9282f107cd383f7676c
--
2017-01-24 15:49:29 receive version message: /bitcoinj:0.14.3/Bitcoin Wallet:5.04/: version 70001, blocks=449806, us=127.0.0.1:8333, peer=274
2017-01-24 15:49:37 UpdateTip: new best=0000000000000000008ce84b11a212f3950dc0d6f1ecccd66361fa2494e73986 height=449807 version=0x20000000 log2_work=85.869022 tx=190354204 date='2017-01-24 15:48:52' progress=1.000000 cache=118.1MiB(57563tx) warning='5 of last 100 blocks have unexpected version'
2017-01-24 15:49:37 AddToWallet a4bdc3db078294e2cf8d935327a40491a7b99d497d473aae9305f346eab76144  update
2017-01-24 15:49:37 AddToWallet 3ed223c549577969cfba7663a324b5642770801303ef140630b8ac1195c7feec  update
2017-01-24 15:49:37 AddToWallet 662b1b2f66179e8be0a055ecaa8728fa069a6974b3b74cfbc87627b7bf50eb76  update
2017-01-24 15:49:37 AddToWallet 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6  update
2017-01-24 15:49:37 AddToWallet b66a224291f1d4ac02ac0d80a67fd4678bff120a2f6b9aeaecffc0ff3a5c0cec  update
2017-01-24 15:49:37 AddToWallet 739688a1de281ef97ceded7a266014f3de656ebacad192b4fe686a95293e9a96  update
2017-01-24 15:49:37 AddToWallet 42138db9663524f808b087725865536e14cff0504badaea59e68c8e9ef0d0521  update
2017-01-24 15:49:37 receive version message: /bitcoinj:0.13.3/Bitcoin Wallet:4.42/: version 70001, blocks=449667, us=127.0.0.1:8333, peer=275
2017-01-24 15:49:37 receive version message: /Bither1.6.0/: version 70001, blocks=449806, us=127.0.0.1:8333, peer=273

bitcoin-cli gettransaction 6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6 gives

{
  "amount": -0.99970000,
  "fee": -0.00015778,
  "confirmations": 24,
  "blockhash": "0000000000000000008ce84b11a212f3950dc0d6f1ecccd66361fa2494e73986",
  "blockindex": 1176,
  "blocktime": 1485272932,
  "txid": "6ff221aee6174acc2263c64b1deec94ddfa1ad0b2877b30ccd580476f08ab7e6",
  "walletconflicts": [
  ],
  "time": 1485214510,
  "timereceived": 1485214510,
  "bip125-replaceable": "no",
  "details": [
    {
      "account": "",
      "address": "1M5r2SLSuwZYtoR1TA1sM3cmnbhk8Z58wn",
      "category": "send",
      "amount": -0.99970000,
      "vout": 0,
      "fee": -0.00015778,
      "abandoned": false
    }
  ],
  "hex": "01000000018add02da742785104a5f72d5a23676c0b3e1099c490438b0de66214fa6e000f6010000006b483045022100fd5cac4f9f453aab0b1f36e84055ccdf464ecd65d35d693fcc6bb5a5e2dbd1d102205aeadaabeb0575b4b25281568de960585e26730baec3e574710fafa5bd4dead6012102f963835d3115b83ede335b2c3386682c08c05d43c541f2366c0eb9b201c57bf9feffffff02d06bf505000000001976a914dc4d1a749f9801748b94a0f9890b88e9b0dfbf9488ac9c806986010000001976a91471655990809fdc834a331322a496b74fb763b9bf88acb0dc0600"
}

do you have a super small maxmempool or so?

Nope. I'm running with a pretty standard configuration:

server=1
rpcuser=bitcoinrpc
rpcpassword=xxxxxxxxx
maxuploadtarget=144
txconfirmtarget=6
txindex=1
keypool=10000

That's it

What about grep "rebroadcast" | grep "unconfirmed transactions"?

Yeah, I have a lot of that :P

2017-01-24 13:47:12 ResendWalletTransactions: rebroadcast 82 unconfirmed transactions
2017-01-24 14:16:16 ResendWalletTransactions: rebroadcast 91 unconfirmed transactions
2017-01-24 15:32:09 ResendWalletTransactions: rebroadcast 72 unconfirmed transactions
2017-01-24 15:53:49 ResendWalletTransactions: rebroadcast 73 unconfirmed transactions
2017-01-24 15:54:33 ResendWalletTransactions: rebroadcast 71 unconfirmed transactions
2017-01-24 16:15:23 ResendWalletTransactions: rebroadcast 73 unconfirmed transactions
2017-01-24 16:42:48 ResendWalletTransactions: rebroadcast 79 unconfirmed transactions
2017-01-24 16:54:58 ResendWalletTransactions: rebroadcast 79 unconfirmed transactions
2017-01-24 17:21:37 ResendWalletTransactions: rebroadcast 100 unconfirmed transactions
2017-01-24 17:32:56 ResendWalletTransactions: rebroadcast 99 unconfirmed transactions
2017-01-24 17:46:12 ResendWalletTransactions: rebroadcast 91 unconfirmed transactions
2017-01-24 18:07:19 ResendWalletTransactions: rebroadcast 86 unconfirmed transactions
2017-01-24 18:47:32 ResendWalletTransactions: rebroadcast 107 unconfirmed transactions
2017-01-24 19:16:41 ResendWalletTransactions: rebroadcast 108 unconfirmed transactions
2017-01-24 19:35:22 ResendWalletTransactions: rebroadcast 92 unconfirmed transactions
2017-01-24 19:44:27 ResendWalletTransactions: rebroadcast 91 unconfirmed transactions

I think the vast majority of them are incoming transactions, accompanied by a support ticket wondering why bitcoin isn't working for them :(

What looks like happened here is the 6ff221a transaction could not be accepted into your mempool at the time you generated it (but it did make it into your wallet). This leads to a known sub-optimal behavior where it still counts as spending all the inputs it consumes but does not count as crediting your balance with any of its outputs regardless of whether they are change or otherwise to you. This explains why your balance "disappeared".

What doesn't make sense is why this situation persisted until a restart? It should have been the case that your node attempted to reaccept that transaction to your mempool roughly every 30 mins. And the most likely guess is it had too many unconfirmed parents to be accepted originally, so as soon as few of them were confirmed in blocks, it should have been accepted into the mempool. However it seems to have not made it back into your mempool until you restarted your node. I haven't been able to come up with a theory on why that might have been the case.

Theory: Actually running 0.13.1 not 0.13.2?

$ bitcoin-cli getinfo
{
  "version": 130200,
  "protocolversion": 70015,
  "walletversion": 60000,

It's possible that when I upgraded to 0.13.2 I forgot to restart my client, but I very much strongly doubt it. I also recall checking to make sure I was on the latest, but I'm not 100%.

Was there an issue in 0.13.1 that could've caused it?

0.13.1 doesn't reattempt the mempool insertion, this was fixed in 0.13.2. Any chance you have enough debug logs to confirm one way or the other? (the logs log the version at start).

(If you were on 0.13.1 this would be a known issue that was fixed in 0.13.2)

The logs don't go that far back, unfortunately. Since there's not probably not an awful lot here for people to work with, I'll just close the issue and try reproduce it (I've now got code that keeps track what my wallet balance should be and if it diverges from what bitcoin reports, I'll know the issue has resurfaced)

@hartley785 Please don't spam multiple issues with comments. If you have a specific technical problem related to Bitcoin Core, please open a new issue, with all the information you have.