wallet: fix mixed-input transaction accounting in history RPCs

w0xlt commented at 10:47 pm on March 19, 2026: contributor

When a wallet owns only some inputs of a transaction (e.g. CoinJoins, payjoins, or other collaborative transactions), gettransaction, listtransactions and listsinceblock currently fabricate “send” entries for outputs the wallet didn’t fund and misattribute the full transaction fee to the wallet. This is because the accounting code treats any nDebit > 0 (i.e. any wallet-owned input) as a full wallet spend.

Fixes this by introducing CachedTxIsFromMeForAccounting, which requires all inputs to be wallet-owned before generating send entries or reporting fees. This is scoped strictly to history/accounting RPCs - the broader CachedTxIsFromMe semantics used by trust evaluation (CachedTxIsTrusted) and spend selection remain unchanged.

Addresses #14136

wallet: scope mixed-input accounting to history RPCs

Introduce a history/accounting-specific all-inputs-owned helper for wallet transaction reporting.

This fixes mixed-input gettransaction/listtransactions/listsinceblock accounting without changing the broader CachedTxIsFromMe semantics used by wallet policy and trust code. Existing wallet_listtransactions coverage is updated to assert the corrected history behavior.

839226725b

test: add mixed-input wallet history regression

Add a focused functional test for mixed-input collaborative transactions.

The test asserts that gettransaction, listtransactions, and listsinceblock do not fabricate send entries or full-transaction fees when only some inputs belong to the wallet, and registers the scenario in the functional test runner.

5c5176ec4c

DrahtBot added the label Wallet on Mar 19, 2026

DrahtBot commented at 10:47 pm on March 19, 2026: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	rkrux

If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#bitcoin-core/gui/933 ([DRAFT] Introduce Qt test automation bridge and gui functional tests by johnny9)
#27865 (wallet: Track no-longer-spendable TXOs separately by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

luke-jr commented at 2:56 pm on March 20, 2026: member

This won’t show even the true send anymore… not sure that’s a good idea.

See #25991 for what is needed to fix this properly.

w0xlt commented at 5:40 am on March 22, 2026: contributor

The goal here, in this PR, is a smaller immediate fix: for mixed-input transactions, the history RPCs should stop reporting send entries and full fees when the wallet cannot attribute them objectively.

#25991 is an interesting direction, but as written it depends on manually providing additional wallet-local per-output metadata. Without that metadata, we still need a safe fallback, and that is what this PR provides.

rkrux commented at 12:24 pm on March 23, 2026: contributor

As I read the related issue #14136, it’s unfortunate that the RPC shows incorrect information in the result - glad that this PR tries to address it.

However, I’m leaning towards a NACK because this PR removes the send category details of such transactions altogether, which is not correct. The wallet does participate (though partially) in sending funds within these transactions and not showing those can be problematic as well.

From #34872#issue-4104631274

Fixes this by introducing CachedTxIsFromMeForAccounting,

I am also not in favour of having two different views of CachedTxIsFromMe - one without accounting and one with. Having two views is also a sign that there is mismatch between what the wallet shows to the user and what the wallet does for the user.

From #34872 (comment):

Without that metadata, we still need a safe fallback, and that is what this PR provides.

Due to the above reasons, I don’t believe this is a safe fallback, and it only replaces one issue by another.

From #34872#issue-4104631274

This is because the accounting code treats any nDebit > 0 (i.e. any wallet-owned input) as a full wallet spend.

It appears that this assumption made by the wallet doesn’t hold true anymore and maybe it needs to be reworked for this issue to be completely fixed.

w0xlt commented at 8:15 pm on March 23, 2026: contributor

@rkrux Thanks for the review. I agree this isn’t a complete solution for mixed-input accounting.

The goal here is narrower: to prevent history RPCs from reporting send entries and full fees that the wallet cannot objectively attribute from the transaction alone.

So I see this as an improvement over the current behavior.

A complete solution likely requires additional attribution metadata. However, that’s tricky - even if we add something like #25991, or a more automated way to set it, the metadata would not survive an importdescriptors restore, since there’s currently no way to import it.

In those cases, we would still need a conservative fallback for history RPCs when attribution is unavailable.

Do you see another way to address this without relying on additional metadata?

wallet: fix mixed-input transaction accounting in history RPCs #34872

Reviews

Conflicts