`listtransactions` does not list tx that spends only change outputs to a change address

whitslack commented at 8:44 am on February 20, 2026: contributor

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

I described this issue in a PR comment here, but @achow101 requested that I open a separate issue, stating that my problem is distinct from the one addressed by that PR.

The problem is that Bitcoin Core v30.2 has apparently forgotten about a transaction that I created, signed, and broadcast to consolidate some outputs. The outputs that I spent in the transaction are no longer listed by listunspent, but neither is the spending transaction listed by listtransactions. My transaction drew three inputs from a single wallet and sent one output back into that same wallet, but that unconfirmed incoming amount is not accounted for anywhere. getbalance and getbalances do not include the amount. Effectively, it looks as though I have simply lost money. I can retrieve the transaction by specifying its TxID to gettransaction, but the transaction does not appear in listtransactions.

Expected behaviour

listtransactions should show all transactions involving addresses in the wallet, even if those transactions are unconfirmed, and even if they have been evicted from the local node’s mempool.

Steps to reproduce

Have three outputs, all sent to the same P2WPKH address. Mine were all sent in different transactions.
Construct a transaction to consolidate the three outputs into a single output to that same address. (Yes, I know that broadcasting this transaction makes the address less quantum-resistant because its EC pubkey is now published.)
```
0$ bitcoin-tx -create in=a1b2…c3d4:0 in=b1c2…d3e4:2 in=c1d2…e3f4:1 outaddr=12.345:bc1q…etc
```
Note: The amount specified in the outaddr argument is exactly the sum of the amounts of the three inputs.

Calculate and deduct a minimal fee from the output.

0$ bitcoin-cli -rpcwallet="${wallet}" fundrawtransaction "${hex}" '{"add_inputs":false,"subtractFeeFromOutputs":[0],"fee_rate":0.1}'

Sign the transaction using the wallet.

0$ bitcoin-cli -rpcwallet="${wallet}" signrawtransactionwithwallet "${hex}"

Broadcast the signed transaction.
```
0$ bitcoin-cli sendrawtransaction "${hex}"
```
Note: No -rpcwallet= argument was specified in this command.

Somehow cause the transaction to be evicted from the local node’s mempool.

0$ bitcoin-cli getrawtransaction "${txid}"
1error code: -5
2error message:
3No such mempool transaction. Use -txindex or provide a block hash to enable blockchain transaction queries. Use gettransaction for wallet transactions.

Attempt to find the transaction in the output of listtransactions.

0$ bitcoin-cli -rpcwallet="${wallet}" listtransactions '*' 10000 | jq --arg txid "${txid}" '.[] | select(.txid == $txid)'

It’s not there.

Query the wallet’s balance.

0$ bitcoin-cli -rpcwallet="${wallet}" -named getbalance minconf=0 avoid_reuse=false

The money is apparently missing!

Query the wallet for the missing transaction.
```
0$ bitcoin-cli -rpcwallet="${wallet}" -named gettransaction txid="${txid}" verbose=true
```
The wallet indeed knows about the transaction and reports "confirmations": 0, yet the transaction is not accounted for anywhere.

Relevant log output

The node’s debug.log does include a line AddToWallet ${txid} new InMempool dated when the transaction was originally broadcast. It also includes another line, dated about 18½ hours later: Submitting wtx ${txid} to mempool for relay. There are no other mentions of the TxID in the log.

How did you obtain Bitcoin Core

Compiled from source

What version of Bitcoin Core are you using?

v30.2

Operating system and version

Gentoo Linux

Machine specifications

Linux 6.12.58-gentoo x86_64

fanquake added the label Wallet on Feb 20, 2026

achow101 commented at 2:06 am on February 21, 2026: member

Following the instruction as written, I’m unable to reproduce this. The transaction shows up as expected in listtransactions.

However, listtransactions does do interpretation of transactions in order to make “logical transactions” to avoid confusing users with various Bitcoin internals (e.g. change, multiple inputs, etc.). This includes excluding outputs that the wallet things are change. If I send to a change address, then the transaction does not show up, and I think that’s the only way to make that happen.

How did you get the address you sent to? What is the output of getaddressinfo for the output address?

We should probably have a listrawtransactions RPC that just outputs all of the transactions known to the wallet without trying to interpret things.

whitslack commented at 2:32 am on February 21, 2026: contributor

@achow101: Thank you for your efforts. The output address is in fact a change address. getaddressinfo reports "ischange": true, and the descriptor from which the address was derived is marked as "internal": true. The use case is merging multiple “dusting attack” outputs into the same address that they had dusted so as to reveal no information to the attacker (other than that the address is still being watched and the private key for it is still known). When the dusting attack is made against an address that had originally been used to receive change, then merging the dust outputs into the change output and reusing that change address means that the merged output will be going to a change address.

whitslack renamed this:
~~Wallet loses track of mempool-evicted raw transaction: inputs still spent, but spending transaction nowhere to be seen~~
`listtransactions` does not list unconfirmed tx that spends only change outputs to a change address
on Feb 21, 2026

darosior commented at 4:42 pm on February 24, 2026: member

@whitslack As an alternative, you may want to use listsinceblock which allows you to set an include_change parameter to true.

whitslack commented at 6:16 pm on February 24, 2026: contributor

As an alternative, you may want to use listsinceblock which allows you to set an include_change parameter to true. @darosior: Thank you! I was previously unaware of that RPC. Yes, indeed, when I call listsinceblock with include_change=true, then I can see my consolidation transaction, which appears twice: once with "category": "send" and again with "category": "receive", which makes sense. The only slight annoyance is the need to choose a suitable blockhash. I just used the block hash from the transaction reported by listtransactions '*' 1 to list all my “filtered” transactions that have occurred since the last unfiltered one. Works well enough, although I do still wish that listtransactions could be told to include transactions to change addresses too.

Incidentally, although my consolidation transaction has now confirmed, it’s still not showing in listtransactions, although now it is included in getbalance.

whitslack renamed this:
~~`listtransactions` does not list unconfirmed tx that spends only change outputs to a change address~~
`listtransactions` does not list tx that spends only change outputs to a change address
on Feb 24, 2026

listtransactions does not list tx that spends only change outputs to a change address #34632