[PoC] cmd/evm: malicious bloated 1559 transactions poc

[holiman]

From the readme in this PR:

EIP-1559 malicious bloat

This test contains testcases for EIP-1559, which tests an attack where transactions are bloated.
The transactions uses a 1Mb-sized integer to specify either max_priority_fee_per_gas or max_fee_per_gas.

What they actually pay is

        priority_fee_per_gas = min(transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas)

So it is possible to dump huge amount of data into one of the fields.
A user can maliciously bombard blocks with no penalty, and a miner can create basically arbitrary large blocks.

There are two transactions in txs.rlp, the first one with 512K max_fee_per_gas (a.k.a feeCap), the second with 512K max_priority_fee_per_gas (a.k.a tip).
The txs.json is what was used to generate the two malicious ones.

This attack is a bit hard to pull off, even on a testnet. In various json-conversions, go-ethereum does not allow
marshallling integers above 256 bits. Further, the txpool rejects oversized transactions, and is also erroneously
calculating the cost of a transaction.

This PoC shows that the consensus engine accepts such bloated transactions. This means that a valid block, post 1559, can be arbitrarily
large, without that extra bloat costing anything (except for the miner who increases the chance to be uncled).

[holiman]

This vector is actually a consensus-bug,

in Nethermind we're using 256 bits fields for MaxPriorityFeePerGas and MaxFeePerGas.

So a block mined with one of these txs would be rejected by Nethermind.

[winsvega]

does t8ntool perform such a check?