Skip to content

Conversation

metalicjames
Copy link

This command is useful for testing the behavior of double-spends when iteracting with Core on regtest. Since this RPC likely should not be used on livenet, it is hidden from help, similarly to invalidateblock.

The intended usecase for this RPC is to allow for conflicting transactions to be added to the mempool that do not satisfy RBF rules. This would allow a fork to be generated with a double-spend in integration tests with other software in order to simulate a reorg and double-spend event.

The RPC itself simply exposes the removeRecursive public mempool method to the RPC interface and introduces a new MANUAL mempool removal reason. The pull request includes a functional test for its intended behavior.

…ts descendants from the mempool

This command is useful for testing the behavior of double-spends when iteracting with Core on regtest.
Since this RPC likely should not be used on livenet, it is hidden from help, similarly to invalidateblock.
@DrahtBot
Copy link
Contributor

DrahtBot commented Aug 1, 2019

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #16899 (UTXO snapshot creation (dumptxoutset) by jamesob)
  • #16365 (Log RPC parameters (arguments) if -debug=rpcparams by LarryRuane)
  • #15873 (Rpc removemempoolentry by IntegralTeam)

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.

@metalicjames
Copy link
Author

metalicjames commented Aug 1, 2019

This is indeed similar to #15873 which I hadn't seen before this. The primary difference is that the RPC is hidden and the test might be a little more comprehensive. I'm also open to making this RPC only available on regtest, since it is only intended for testing purposes.

@promag
Copy link
Contributor

promag commented Aug 6, 2019

@metalicjames have you read the suggestions in #15873?

@metalicjames
Copy link
Author

@promag I could modify code from Core's tests to generate my own blocks for testing in my project, but that seems vastly out-of-scope for what I'm trying to do. It would be much easier to orchestrate a double-spending reorg on regtest using existing RPCs with the addition of this one.

@jnewbery
Copy link
Contributor

Concept NACK, for the same reasons given in #15873

@maflcko
Copy link
Member

maflcko commented Sep 16, 2019

I think your particular use can can be achieved with something like #10823 (potentially in combination with prioritisetransaction)

@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 5, 2019

Needs rebase

@fanquake
Copy link
Member

Going to close this re the discussion in #15873.

@fanquake fanquake closed this Feb 25, 2020
@andrewtoth
Copy link
Contributor

@metalicjames Just wanted to bring #17693 to your attention.

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants