wallet: balance gone when tx broadcast failed

decryp2kanon commented at 9:39 am on January 15, 2021: contributor

on BTC mainnet. I set the txfee as minimal (custom 0.00001 per kilo) and it failed. The problem is displaying my balance as 0 (on QT GUI side) until abandon this tx. I was very scared.

v0.20.1

02021-01-15T09:26:27Z [default wallet] AddToWallet xxx  new
12021-01-15T09:26:28Z [default wallet] Submitting wtx xxx to mempool for relay
22021-01-15T09:26:28Z [default wallet] CommitTransaction(): Transaction cannot be broadcast immediately, mempool min fee not met, 142 < 152
32021-01-15T09:29:10Z [default wallet] Fee Calculation: Fee:17407 Bytes:142 Needed:17407 Tgt:0 (requested 0) Reason:"PayTxFee set" Decay 0.00000: Estimation: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out) Fail: (-1 - -1) -nan% 0.0/(0.0 0 mem 0.0 out)

decryp2kanon added the label Bug on Jan 15, 2021

decryp2kanon renamed this:
~~balance gone when tx broadcast failed~~
[QT] balance gone when tx broadcast failed
on Jan 15, 2021

MarcoFalke added the label Wallet on Jan 15, 2021

MarcoFalke renamed this:
~~[QT] balance gone when tx broadcast failed~~
balance gone when tx broadcast failed
on Jan 15, 2021

MarcoFalke renamed this:
~~balance gone when tx broadcast failed~~
wallet: balance gone when tx broadcast failed
on Jan 15, 2021

fyquah commented at 8:48 pm on February 24, 2021: contributor

I think a partial fix for this would be:

Change the return type of SubmitMemoryPoolAndReturn (https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L506) to an enum class TEMPORARY_FAILURE / PERMENANT_FAILURE / SUBMITTED.
In the case of PERMENANT_FAILURE, we can delete the transaction from the wallet immediately (https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L3182)

If that’s sounds right, I’d submit a patch for this in the coming days

Crypto2 commented at 8:45 pm on April 21, 2021: none

Is this still active and does it affect getwalletinfo/getbalance? We’re having a problem where our balance keeps reporting lower and lower over time but if you restart bitcoind it’s back to normal. I’ve only seen it happen like 2-3x before but since the blockchain backed up on Friday it’s been worse and worse. Is there any fix without restarting?

We do have a fair amount of consolidation TXes from before the blockchain backed up with low fees set so I had kind of thought maybe it’s ignoring TXes with too low of a fee rate but saw this issue and it makes sense too.

willcl-ark commented at 2:35 pm on March 8, 2023: member

02021-01-15T09:26:28Z [default wallet] CommitTransaction(): Transaction cannot be broadcast immediately, mempool min fee not met, 142 < 152

This error is surfacing from Prechecks() checking the fee rate:

https://github.com/bitcoin/bitcoin/blob/8d12127a9c19cb218d661a88ab9b6871c9d853b9/src/validation.cpp#L847-L850 @achow101 should it be the case that the wallet can create a transaction, which would fail ATMP(test_accept=true) but still result in a balance reduction for the user? My intuition would be that if the created tx was failing ATMP PreChecks that the coins would not appear as debited from the wallet balance, but my understanding of when coins are reserved/used, and balances updated in the wallet is still a bit limited 😞

achow101 commented at 2:56 pm on March 8, 2023: member

should it be the case that the wallet can create a transaction, which would fail ATMP(test_accept=true)

No.

but still result in a balance reduction for the user?

Yes, ish. It is not a balance reduction per se, we don’t track the balance as a number that gets incremented and decremented as transactions are made. Rather the balance is (re)computed by examining all txs and adding up the outputs that belong to the wallet. One of the criteria is that unconfirmed transactions need to be in our mempool to be counted as part of the “trusted” balance. A transaction which failed to make it into the mempool will result in the wallet recording that the parent has had all of its outputs spent (so it does not increase the balance), but that the child transaction is not trusted, so change back is not counted. This is intentional as we prefer to err on the side of telling the user that they have less money than they may actually have.

The issue with getbalance is figuring out what unconfirmed things should be included in the balance as unconfirmed transactions can be in a variety of states and possibilities of being confirmed. getbalances (with an s) provides a more complete picture of the balance of the wallet.

willcl-ark commented at 9:39 am on March 9, 2023: member

…the balance is (re)computed by examining all txs and adding up the outputs that belong to the wallet.

indeed

One of the criteria is that unconfirmed transactions need to be in our mempool to be counted as part of the “trusted” balance. A transaction which failed to make it into the mempool will result in the wallet recording that the parent has had all of its outputs spent (so it does not increase the balance), but that the child transaction is not trusted, so change back is not counted. This is intentional as we prefer to err on the side of telling the user that they have less money than they may actually have.

OK, so this seems like the root cause of the issue here. Although it doesn’t explain to me how @decryp2kanon was managing to make a transaction in the GUI (presuming that was how it was made) which failed ATMP checks and triggered this.

Is there actually any fix to be provided here, or should the guidance simply be to use getbalances instead to get the complete picture?

wallet: balance gone when tx broadcast failed #20943