@MrChico thank you for bringing this up! My initial reaction is that this should be a separate EIP because while EIP1559 potentially exasperates this issue (I’ll get to that at the end) it’s not specific to EIP1559.
There are a few reasons why that assumption is already not safe to make even with standard miners/clients. I apologize and please correct me if I am wrong on any of these points or if I misunderstood you.
Parity has a CLI flag
--tx-queue-strategy that lets you customize how your miner prioritizes transactions (this might be for the miner pool only with standard sorting still done before committing, I’m not super familiar with Parity)
Geth sorts and commits local and remote transactions separately, it commits all local transactions before moving to the remotes
Within the local and remote batches the transactions are sorted by nonce and gas price, with nonce taking precedence. More specifically, in NewTransactionsByPriceAndNonce we iterate through a map of addresses to nonce-sorted transactions, taking only the lowest-nonce transaction for each address and adding it to a heap which is sorted by gas price. Transactions are read from the heap here and after they are committed they are replaced with the next lowest nonce transaction for that account and the heap is re-sorted.
E.g. let’s say we have 2 remote accounts A and B
A has three transactions with nonce n and gas price p: A(n:0, p:100), A(n:1, p:200), A(n:2, p:100)
B has three transactions: B(n:0, p:200), B(n:1, p:50), B(n:2, p:400)
And one local account C with a single tx: C(n:0, p:50)
The final ordering (as I understand it) will be: C(n:0, p:50), B(n:0, p:200), A(n:0, p:100), A(n:1, p:200), A(n:2, p:100), B(n:1, p:50), B(n:2, p:400)
As for how EIP1559 relates to this all…
This implementation currently retains the above ordering of transactions using either legacy or EIP1559 gas price. During the transition period during which both legacy and EIP1559 transactions are accepted, since
EIP1559_GASPRICE = min(BASE_FEE + GAS_PREMIUM, FEE_CAP) and the
BASE_FEE is always burned a miner will be rewarded more for a
LEGACY_GASPRICE < EIP1559_GASPRICE so long as
LEGACY_GASPRICE > GAS_PREMIUM or
LEGACY_GASPRICE > FEE_CAP - BASE_FEE if
FEE_CAP < BASE_FEE + GAS_PREMIUM.
We can prescribe a new ordering based on
FEE_CAP - BASE_FEE instead, that would remove the new incentive but then the standard itself would no longer be to order by gas price as it does now. The other way would be what you recommend and include tx ordering under consensus
Curious what other people’s thoughts are. I can bring this up at the Core Dev’s call this Friday.