Scotty

Does #2272 close this issue?

@jochem-brouwer This is different than the `RangeProof` work you're doing, right? If so I will start looking into it.

The CI won't automatically run this test yet. Can be tested manually with (from packages/evm): `npm run test:state` `npm run test:state: allForks` `npm run test:state:SelectedForks` `npm run test:state:slow`

> The greatest problem I have for now is that we replicate far (far) too much code with this for now. So > 1.000 LOC is by far too much...

> The one thing we can think about is to extract the whole test runner (everything in tester, not sure @jochem-brouwer, retesteth as well?) into a separate folder evm-vm-test-runner or...

@holgerd77 Finally got everything to pass, without touching anything outside of `util` Could use a sanity check but I think this is done.

@holgerd77 I did another round on this and have everything passing. * I needed to tweak something in `LegacyTransaction` to allow the `tx` tests to pass. * Changing this in...

To achieve the same result without changing any defaults, I created a config option called `disableMinerHardforkByBlockNumber`, and applied it to the failing tests in `miner.spec.ts` and `pendingBlock.spec.ts` The way the...

> I would put this on hold for now, I do not have the energy/ressources to properly review this in time before our final releases so this will likely not...

This seems directly related to something I encountered in the `miner` test during: #1995. There is a test in `miner.spec.ts` where we build a `FakeChain`, and assign hardforks to blockNumbers...