Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transactions in mempool that conflict with wallet transactions are not (always) shown in GUI or RPC #12883

Open
setpill opened this issue Apr 4, 2018 · 4 comments
Labels

Comments

@setpill
Copy link
Contributor

@setpill setpill commented Apr 4, 2018

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.

rbfdoublespend1

rbfdoublespend2

rbfdoublespend3

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.

@Sjors

This comment has been minimized.

Copy link
Member

@Sjors Sjors commented Apr 4, 2018

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.

@setpill

This comment has been minimized.

Copy link
Contributor Author

@setpill setpill commented Apr 6, 2018

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.
@setpill

This comment has been minimized.

Copy link
Contributor Author

@setpill setpill commented Apr 9, 2018

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.

@salmanfarisk

This comment has been minimized.

Copy link

@salmanfarisk salmanfarisk commented Jun 8, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.