Also posted this on the PR, but reposting here.
An upgrade will activate at a Transition Eligible Block if all of the following are true:
- The upgrade has not activated already.
- The timestamp of the block is on or after the
- The previous Transition Eligible Block was on or after the
A is the previous TEB, and
B is the current
TEB, and the third bullet dictates that
A is on or after
TRANSITION_TIME, then there’s no need for the second bullet, since
B is already defined to be after
(See EDIT below, the reasoning here is incorrect)
A separate problem, and IMO probably bigger problem, is that
ommer blocks have no restrictions on time. So it’s fully possible to set an ommer block timestamp to one year in the future. Now, the parent of the
ommer will be a
canon block, so if we require the parent to be past the
TRANSITION_TIME, a (malicious) miner can’t include future-fork ommers at will.
Not until after
TRANSITION_TIME, let’s say there’s another ~week before the next
TEB. In that period, miners could include forked ommers (meaning: ommer-blocks with future timestamps, which should be interpreted with the new rules) on every block.
It’s a bit unclear how that should be handled, and it may be depending on EIPs. For example, if we have a fork which redefines the PoW, then it means that when importing a block
N (pre-fork), we might have to use post-fork rules to determine the header validity for the included ommer PoW.
These variations never occur on number-based forks, because we always know that block
N only includes ommers with lower numbers, so the ommer can never be subject to
future rules. This EIP changes it, so that an ommer can be subject to
future fork rules.
I misunderstood the proposal. My reasoning above is flawed, since only an ommer with a particular
(block.number % TRANSITION_INCREMENT) == 0 can be a fork. That means a miner can’t litter the chain with fork-enabled ommers.