Thanks. Now imagine a 0.19.5 which inclides your change is available. Some of the witnesses start applying it. We are in a round where some witnesses (say 5 of the first 20) run 0.19.5 (with the modification) and the remaining ones (15 plus the backup) run 0.19.4 without the modification. Some "author reward" transactions come up for processing for the next block and one of the witnesses who has applied 0.19.5 is up for signing that one. What happens there ? In theory the author reward should be processed with the rules of 0.19.4 because your modification hasn't been approved yet by 17 witnesses. But because this witness has applied 0.19.5 his results will be different, his block will be considered "out of consensus" and thrown out, is that correct ? Which indicates that witnesses are well advised to do the coordination "out of band" in a chat so that the disruption is minimized, correct ?
You are viewing a single comment's thread from:
That's not really how it works..
It is just a technicality, but the version numbers are based on whatever hardfork version it is in. A change to 19.5 can not be one that causes a fork from a previous version of 19. If it is a hardfork, then it will be version 0.20.0.
Whenever there is a hardfork, there is a specific point in time where all the nodes will switch if there is at least 17 'yes' votes.
If I apply hardfork 20, then I am voting 'yes' for that change. Even though I am voting yes, I am still processing blocks in 'hardfork 19' mode unless/until 17/21 witnesses accept, and the hardfork occurs at whatever time it is scheduled to happen in the code.
Thanks, does that also imply that if by the time HF "X" is scheduled to happen in code there are less than 17 witnesses signalling "yes" then the HF fails ?
correct