First pass. Haven't tested this at all and this was just first thoughts. EDIT: Initially way over-complicating things and assumed that we should respond to a block proposal based on who the current sortition winner is. However, if a miner proposes a block proposal that does not link to the correct consensus hash (odds are it will be rejected first off), it does not actually really matter. We will simply let the proposing miner know that the tenure extend for that timestamp has passed or not. It only matters that a valid sortition winner knows this for a valid proposal/valid attempt to tenure change. This simplified things a lot as I could just respond to every block proposal based on its provided consensus hash.
aldur
commented
6 days ago
First pass. Haven't tested this at all and this was just first thoughts. EDIT: Initially way over-complicating things and assumed that we should respond to a block proposal based on who the current sortition winner is. However, if a miner proposes a block proposal that does not link to the correct consensus hash (odds are it will be rejected first off), it does not actually really matter. We will simply let the proposing miner know that the tenure extend for that timestamp has passed or not. It only matters that a valid sortition winner knows this for a valid proposal/valid attempt to tenure change. This simplified things a lot as I could just respond to every block proposal based on its provided consensus hash.