How to replace transactions in a free gas (no-gas) network

[philipbeaucamp]

The documentation states that transactions can be replaced by sending another transaction with identical nonce and higher gas price (as well as higher effective priority free) as determined by the --tx-pool-price-bump option.

For private networks with zeroBaseFee=true, how can one replace transactions? The documentation addresses free gas networks but it doesn't provide an answer, only that setting any value other than 0 --tx-pool-price-bump will cause an error. However it look like I have to increase the gas price because I otherwise get a 'known transaction' (when resending the same transaction) or 'replacement transaction underpriced' error.

Ideally I'm looking for an answer for both post and pre london fork (eip 1559), but any help is appreciated.

[jframe]

@philipbeaucamp Can you provide some more details on why you need transaction replacement on a free gas network?

[jframe]

@matthew1001 Any thoughts on how this can be done?

[philipbeaucamp]

@jframe We've had transactions (with the correct nonce) being stuck in the transaction pool before, neither failing nor being mined. The why is not quite clear to us but in order to free up the pool I'd like to replace the transaction with a no-op transaction (sending zero ether to own address).
Another use case (althought less relevant) could to to simply replace pending transactions in the memory pool, for example transactions that have been sent with a future nonce.
Perhaps the latter case might seem a bit contrived, but the fact is that this is doable in a non gas-free network, so I'd like to know how to replicate this behaviour in a gas-free network.

[matthew1001]

For a free-gas chain we put a change in to allow for TX replacement where it's not possible to bump the gas price. If you have min-gas-price set to 0 I would expect you to see this in your logs on startup:

2024-10-01 10:30:43.936+00:00 | main | WARN  | Besu | Forcing price bump for transaction replacement to 0, since min-gas-price is set to 0

It's possible that the docs need an update to document this change. It was designed to resolve exactly the issue you are seeing. Which version of Besu are you running?

As for the reason the transactions might get stuck, there aren't many with the sequenced transaction pool. I think if the gas estimate for the transaction is > than the maximum gas per block you might see the TX get stuck. If you enabled TRACE logging I believe it logs out the reason why a TX is considered for a block and then disregarded. Trace can be kind of noisy but you only need to enable it long enough for a block to be produced.

[philipbeaucamp]

I believe the issues were happening on an older version of besu, which didn't run the 'sequenced' transaction pool.
I'll be running more tests on the latest besu with sequenced tx pool soon and report back if I run into issues.