I support service which provide transactions history for users and accept their transactions for sending to network through bitcoind. Sometimes by some reason users transactions stuck for long time (very small percent). While blockexplorers kick users transactions from their mempool (which looks for users that their transaction not exists anymore), bitcoind which used by service still hold it. Previously for removing such transactions I was need stop bitcoind, remove mempool.dat and start bitcoind again. This is not good way for removing just 1 transaction from whole mempool. With this new RPC command removing stuck tx from mempool will be much easier.

I think this PR is the result of a misunderstanding of how transaction propagation and confirmation works in Bitcoin.

While blockexplorers kick users transactions from their mempool (which looks for users that their transaction not exists anymore)

I expect that the vast majority of block explorers are backed by a Bitcoin Core node. The mempool will not remove a transaction except for:

• expiry (if the transaction has been in the mempool for two weeks and is not confirmed)
• limiting (the mempool is full and low-feerate transactions are removed from the bottom)
• removeForBlock (removes any transactions that were included in or conflicted in a confirmed transaction in the blockchain)
• replacement (replaced by fee under BIP 125 rules)

Removing a transaction from your local mempool will not result in that transaction being removed from anyone else's mempool. Even if you then create a new transaction that spends the same inputs, it will not cause the original transaction to be displaced in other node's mempools (except if it meets the BIP 125 conditions).

Perhaps I'm misunderstanding the original motivation for this PR. If so, can you give more details?

Agree with @jnewbery. Even though some miners run full-rbf, it might be easier and cleaner to use BIP 125 for now.

I agree that mempool will not remove transaction, while it not expired/limited/included/replaced. I also realize that if transaction broadcasted to network we can not remove it from network, while somebody else hold it. But, by some case bitcoind (0.17.1) hold broadcasted transaction, while it was removed from blockchain.info/blockchair.com/etc.
I'm sorry, but I can not provide more details, because this happened just few times in my experience.

JFYI, parity has such method: parity_removeTransaction

We've rejected this change before when it came without a really clear justification for its usefulness. I haven't seen anything yet to change my mind there.

Being in bitcoind while blockchain.info has removed it is not, in and of itself, a good case for it.

One thing this would be useful for would be testing mining replaced transactions in regtest. Unless I'm overlooking a way to do this, there isn't really a way to replace a transaction using RBF, then instead mine the transaction that was replaced. This is a common scenario on mainnet, since your replaced transaction might not propagate to a miner in time.

The workflow to do it with this rpc would then be: sendrawtransaction to add the transction to mempool, sendrawtransaction with replacing transaction, removemempoolentry to remove the replacing transaction, then sendrawtransaction with the original transaction again, which won't propagate to peer mempools, and then generatetoaddress.

Unless I'm overlooking a way to do this, there isn't really a way to replace a transaction using RBF, then instead mine the transaction that was replaced.

You can construct and mine blocks directly from the python test framework, without bitcoind RPCs.

@sipa I'm talking about testing external systems systems which are talking to bitcoind, not using the python test framework.

@andrewtoth the same thing applies to whatever creates the block in the test, it can just manually inject the transaction.

I like the idea of this rpc method since I've also personally needed to restart bitcoind in order to flush the mempool. Can someone explain though, could it be abused by any way?

I suppose for my use case using this rpc would be a hack. A better solution would be modifying the generatetoaddress rpc to take a list of raw transactions to include in the block.

Simply rewrite the def create_block in the test framwork (or translate it to the language your test framework is written)

If anyone needs this feature on mainnet, I fail to see why this can´t be achieved by BIP-125 (with the additional advantage that the remainder of the network and miners will also switch out the transaction)

The case I am talking about is not using a test framework, but using bitcoind in regtest. For testing a system that listens directly on the zmq interface and makes requests using rpc, it would be nice to be able to have an rpc that could generate a block with specified txs instead of using whatever is in the mempool.

@andrewtoth I think that's a reasonable thing to add (an RPC to generate a block with specified contents).

I think this is slightly less bad if it's for testing only (hidden rpc, only functions on regtest), but I'd still prefer not to add it if there are other ways to achieve the same thing.

@andrewtoth - could you start a bitcoind in -blocksonly, then explicitly feed it the transactions you want to include in the block via the sendrawtransaction RPC or a -whitelist peer, and then generate the block?

@jnewbery Yes that is a workaround to achieve what I want, but it requires running a second bitcoind.

I think #7533 is a cleaner solution to the desired goal as I understand it? (Despite the PR closed status, I have continued to maintain it, and it is available in Knots already.)

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

Conflicts

No conflicts as of last run.

Doesn't seem to be any consensus that this is a good idea, or would be merged. Going to close this for now. Commenters might be interested in #17693 instead.