What behavior did you expect?

When the mempool contains a transaction that conflicts with a wallet transaction, for this to (always) be visible in both bitcoin-qt GUI and bitcoin-cli output.

What was the actual behavior (provide screenshots if the issue is GUI-related)?

RPC: If the conflicting transaction touches the wallet (eg. if you are the sender, or if you are the recipient and we are considering an honest RBF feebump), the conflict is visible in the (undocumented) walletconflicts return value of the listtransactions and gettransaction RPC calls. In the case the conflicting transaction does NOT touch the wallet (eg. if you are the receiver of a maliciously doublespent RBF transaction), this is not indicated.

GUI: If the conflicting transaction touches the wallet (eg. if you are the sender, or if you are the recipient and we are considering an honest RBF feebump), all versions are visible in the GUI, without indication of conflict between them, but the "pending" part of the balance (correctly) does not show a duplicate amount of incoming money. In the case the conflicting transaction does NOT touch the wallet (eg. if you are the receiver of a maliciously doublespent RBF transaction), there is no indication of any conflict (pending balance still counts the incoming transaction that has been doublespent) aside from the transaction details stating it is not in the mempool.

How reliably can you reproduce the issue, what are the steps to do so?

Very reliably; screenshots provided are from 3 interconnected regtest nodes, the top node has mined some coins and has first spent them to the middle node, RBF-feebumped that transaction (only second transaction shown in screenshots), RBF-doublespent it to the bottom node, then RBF-doublespent it to itself. All nodes have only the latest transaction in the mempool.

What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)?

Version 0.16.0, pre-compiled version from bitcoincore.org.

More broadly, I'd like to see some sort of warning if an incoming transaction is replaced by one with a reduced (or zero) amount going to the wallet.

Related scenario:

• 2 regtest nodes; node0 and node1
• node0 sends 10 BTC to node1 (~40 BTC change) in tx0A
• node0 RBF-doublespends ~50 BTC to itself in tx0B that conflicts with tx0A
• node0 spends the output of tx0B to send 5 BTC to node1, ~45 BTC change in tx1B

Outcome:

• 5 BTC pending balance in node1 (expected)
• node1 has 2 incoming transactions; tx0A and tx1B, these are not in each other's walletconflicts because only tx1B's parent (tx0B) spends the same outputs as tx0A and is therefore "directly conflicting"

Expected:

• node1's incoming transactions (tx0A and tx1B) should be in each other's walletconflicts since they are wallet-touching transactions that are mutually conflicting.

Adding the sending address as watch-only using importaddress is an effective (but ugly) workaround; pending balance goes to zero on an RBF-doublespend, walletconflicts is filled.

Have any progress for this kind of issue...??

Not sure if this feature will be of any use. You shouldn't be trusting txs signed by a third party until they are confirmed sufficiently.

Also, there are other reasons why a transaction can leave the mempool. See https://github.com/bitcoin/bitcoin/blob/dc9d6626835ec2864dfa747c12071dabdc95b919/src/txmempool.h#L349

Also, if the replacement tx is replaced itself again, do you also want to keep that tx in your wallet even though it has no effect on it and will only bloat your wallet?

Agreed wrt. shouldn't trust unmined 3rd party txes. But as described in the original report, the wallet shows inaccurate information, and it would be nice to have a warning that a pending incoming tx was replaced.

Also, if the replacement tx is replaced itself again, do you also want to keep that tx in your wallet even though it has no effect on it and will only bloat your wallet?

No, that wouldn't be desirable, hence why the workaround is ugly.

I'd say that walletconflicts, replaced_by_txid, and replaces_txid are only meaningful and valid for txs that were signed by your own wallet, for example for a a fee bump. Not sure if this can be improved with documentation.

Maybe you could explain the use case you need this for, and why let's say "trusted" isn't enough to check.

It should be noted that this issue was just randomly stumbled across when playing around with regtest, and reported as a "bug" in the sense of "this doesn't work as I expected". As such, there isn't a specific use case I practically need this for. However, for illustrative purposes, here is a hypothetical but realistic use case:

• Merchant website, being able to give user rich feedback on pending payment status. E.g. to show a warning if a payment is unlikely to succeed, due to it being RBFed by a tx that does not pay out to merchant.

Yeah, I think that the user knows it best themselves if they asked their wallet to sign a tx to feebump/cancel (or do some other kind of rbf), so there wouldn't be a need for the merchant to tell the user what they already know. (If they really wanted to, they could do that once the original tx has either +1 or -1 confirmations. To avoid giving out a false alarm if the original tx still makes it in.)

@MarcoFalke @setpill

Merchant website, being able to give user rich feedback on pending payment status. E.g. to show a warning if a payment is unlikely to succeed, due to it being RBFed by a tx that does not pay out to merchant.

This is exactly my case: I'm using bitcoin wallet to show progress of the particular transaction. So transaction might be stuck forever in the wallet with confirmations:0 if the end user sends an RBF transaction and double spends it to his own address. Such specific transaction will have walletconflicts: [], bip125-replaceable: true (sometimes "bip125-replaceable": "unknown") and trusted: false.

You can't rely on trusted because legitimate transactions with bip125 off also have trusted: false.

Also you can't check mempool for the transaction, as transaction could be ejected from the mempool if mempool is more than 300 MB.

Adding the sending address as watch-only using importaddress is an effective (but ugly) workaround; pending balance goes to zero on an RBF-doublespend, walletconflicts is filled.

It seems to be a very ugly workaround also will the wallet import all other transactions related to that sending address and treat them as it's a wallet transaction?

Is there any way to reliably detect such transaction and remove it from the wallet?