It shouldn't be on non-"send" transactions at all, no matter what we know of their inputs...?

It would be great if bitcoind reported the fee of unconfirmed non-send transactions (possible because all the spent outputs are still available). Even better if it kept the fee in the wallet transaction db and made it permanently available.

But this PR only meant to correct the documentation according to the current behavior. Perhaps a new issue should be opened for improving it? (since I won't be able to contribute much to making it happen, I didn't feel comfortable opening one)

The current "fee" field exists to indicate an effect on your wallet.
The fee of incoming transactions has no such effect.

Furthermore, the fee on incoming transactions isn't by itself relevant to the recipient at all: what you care about is the best feerate, including descendants.
But that seems like a feature request for a new field.

I misunderstood your previous comment, I thought you were suggesting that it should include the fee if we know the enough about the inputs to determine it. I now understand that you meant the exact opposite :)

Just to clarify: this PR is about "send" transactions with inputs that are external to the wallet (i.e. coinjoined), not about supporting non-"send" transactions.

I do agree with your point, looking at just the direct fee on its own without taking the feerate of unconfirmed parents and descendants into account isn't very useful. I found myself in the position of needing to report the fee for compatibility with an existing protocol, but now I'm re-considering if that's the right thing to do - perhaps its better to show no fee than a misleading one.

(This could even potentially be abused by making a transaction paying just the relay fee, then a descendant transaction with a high feerate paying to a victim to make him mistakenly believe that its likely to get confirmed soon. But thankfully no one is accepting unconfirmed payments, right? 😛)

I agree that if we report fee for not purely from-us transactions, it should be a different field. Right the invariant holds that the sum of amount and fee fields is the effect of the transaction on the wallet's balance.

Though if it's just for unconfirmed transactions, getmempoolentry may be what you want?

The current "fee" field exists to indicate an effect on your wallet.

This is not documented nor tested in that way and users generally assume this is a bug instead of a feature:

• rpc: Wrong gettransaction info for a coinjoin #14136
• Bitcoin-core 0.15.1 gettransaction showing wrong fee for some transactions #12364

@MarcoFalke Hmm, so its not "unavailable" like I thought and not just a matter of fixing the documentation, its actually reported wrong. An initial fix could be to do what's described here, but I guess its best to close this PR for now until this gets implemented? The documentation can be updated alongside the fix.

Bitcoin Core does not support CoinJoins, and if CoinJoins are generated externally, it is impossible for Core to track them correctly (it's as blind to the metadata as third parties are).

To fix that would require some kind of metadata telling Core which outputs are actually ours, and the CoinJoin software to report that information to Core.

The wallet will happily add coinjoins to the database. If this is not supported, at the very least it should be documented as such.

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #22798 (doc: Fix RPC result documentation by MarcoFalke)

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.

🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

• Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
• Is it no longer relevant? ➡️ Please close.
• Did the author lose interest or time to work on this? ➡️ Please close it and mark it 'Up for grabs' with the label, so that it can be picked up in the future.

Closing for now per previous comment, can be reopened or a new pull can be created any time.