Add removemempoolentry RPC to evict transactions from the mempool #16523

1. 
   metalicjames commented at 8:33 pm on August 1, 2019: none

   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.

2. Add removemempoolentry RPC which manually removed a transaction and its 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.

   a95ba2ade5
3. fanquake added the label RPC/REST/ZMQ on Aug 1, 2019
4. 
   DrahtBot commented at 11:35 pm on August 1, 2019: member

   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.

5. 
   metalicjames commented at 11:44 pm on August 1, 2019: none

   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.
6. 
   promag commented at 11:03 pm on August 6, 2019: member

   @metalicjames have you read the suggestions in #15873?
7. 
   metalicjames commented at 7:20 pm on August 11, 2019: none

   @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.
8. 
   jnewbery commented at 6:20 pm on September 15, 2019: member

   Concept NACK, for the same reasons given in #15873
9. 
   MarcoFalke commented at 7:27 pm on September 16, 2019: member

   I think your particular use can can be achieved with something like #10823 (potentially in combination with prioritisetransaction)
10. 
    DrahtBot commented at 7:02 pm on November 5, 2019: member
11. DrahtBot added the label Needs rebase on Nov 5, 2019
12. 
    fanquake commented at 2:09 am on February 25, 2020: member

    Going to close this re the discussion in #15873.
13. fanquake closed this on Feb 25, 2020

    ---

14. 
    andrewtoth commented at 4:30 am on February 28, 2020: contributor

    @metalicjames Just wanted to bring #17693 to your attention.
15. DrahtBot locked this on Feb 15, 2022

Contributors
metalicjames DrahtBot promag jnewbery MarcoFalke fanquake andrewtoth

Labels
RPC/REST/ZMQ Needs rebase