Just to tie off my previous comments: I’m in favor of immediate timestamp-based forking.
I don’t think the time squeezing attack is likely to be effective without 51% collusion.
Time spreading is already informally prevented, when clients reject blocks that are more than 15-seconds ahead of their wall clock. We can just formalize this across clients, and test for it in Hive. (traditional consensus testing doesn’t help here)
We ought to formalize some things about uncles:
- Uncle bodies are not used for validation, only the header. We validate the PoW, difficulty update, etc, but not transactions.
- Uncles may belong to a fork ahead of the including block. Validation is based on the uncle’s block time. The uncle rewards are based on the including block’s rules.
Last, we need to limit how far an uncle can be ahead of its including block, by timestamp. Allowing an uncle to be as much as 300 seconds in the future should be plenty of flexibility, while still preventing any “fork reassignment” in the future.
Note that in this approach, client devs can’t “refactor” the timestamp fork to a block number fork after activation. Activation needs to permanently be based on time. Refactoring to block number doesn’t play nicely with the p2p fork IDs anyway, so no big loss.