Wallet RPC semantics: gettransaction.confirmations returns large negative values for RBF-replaced transactions (undocumented behavior) #34056

1. 
   husstege-e commented at 11:12 am on December 12, 2025: none

   Is there an existing issue for this?

   • I have searched the existing issues

   Current behaviour

   When using Replace-By-Fee (RBF) in combination with wallet rescans, the wallet RPC reports transactions with negative confirmation counts (e.g. -900, -1200), long after the replacing transaction has been confirmed.

   These negative confirmation values persist even when:

   • the replacement transaction is deeply confirmed
   • the original transaction is fully conflicted and no longer in the mempool
   • wallet balances and UTXO sets are otherwise correct

   The negative value appears to encode “distance since replacement” rather than an actual confirmation count.

   Expected behaviour

   Once a transaction has been replaced via RBF and the replacement transaction is confirmed, the original transaction should report a stable and documented state.

   Specifically:

   • confirmations should not become increasingly negative over time
   • confirmation values should have a clear and documented semantic meaning
   • wallet RPC consumers should not need to infer hidden meanings from confirmation numbers

   Steps to reproduce

   1. Create a wallet on regtest
   2. Send a transaction with BIP125 replaceable flag enabled
   3. Trigger a wallet rescan
   4. Perform a bumpfee (RBF replacement)
   5. Mine blocks to deeply confirm the replacement transaction
   6. Query gettransaction for the original transaction

   Observation: The original transaction reports large negative confirmation counts (e.g. -900, -1200), even though the replacement transaction is confirmed.

   • regtest mode
   • default wallet settings
   • descriptor wallet
   • RBF enabled
   • wallet rescan invoked via RPC

   Relevant log output

   See attached JSON excerpts showing:

   • negative confirmation values
   • walletconflicts
   • replaced_by_txid relationships

   The following excerpts show a replaced RBF transaction reporting large negative confirmation counts long after its replacement has been deeply confirmed. There is no chain reorg and wallet balances are correct.

   The negative confirmation value continues to decrease as new blocks are mined, even though the replacing transaction is already confirmed.

   This raises a question about RPC semantics: is confirmations for replaced transactions intended to represent a negative distance to the replacing transaction’s confirmation height, and if so, where is this behavior documented?

   gettransaction.json gettransaction-replace.txt getbalance.txt

   How did you obtain Bitcoin Core

   Compiled from source

   What version of Bitcoin Core are you using?

   v27.0

   Operating system and version

   Ubuntu 22.04 LTS

   Machine specifications

   x86_64 system, local regtest environment, SSD storage

2. 
   maflcko commented at 11:54 am on December 12, 2025: member

   undocumented

   To get the documentation, you can use the help RPC. It will explain and document the output. E.g.

   0  "confirmations" : n,              (numeric) The number of confirmations for the transaction. Negative confirmations means the
   1                                    transaction conflicted that many blocks ago.
   

3. maflcko closed this on Dec 12, 2025

   ---

4. maflcko added the label Docs on Dec 12, 2025
5. maflcko added the label Wallet on Dec 12, 2025
6. maflcko added the label RPC/REST/ZMQ on Dec 12, 2025
7. maflcko added the label Questions and Help on Dec 12, 2025

Contributors
husstege-e maflcko

Labels
Docs Wallet RPC/REST/ZMQ Questions and Help