You are viewing a single comment's thread from:
RE: I submitted my first hardfork pull request to the Steem blockchain! (Updates to the SBD print rate.)
Very good approach, I am fully with you on the need for the community to step up and live the "decentralized" idea in full - not only decentralized operations but also a community of developers that is decentralized and generates new ideas faster than in a centralized setting.
With the "selection mechanism" of the witness approval vote - which BTW happens where, in github or in steem.chat or is it simply by upgrading the code they run ? I'm curious how things work during the transition period - when some witnesses have upgraded but others not - what happens to a specific payout then depends on what version runs on the node that processes the "author reward transaction", right ?
Witnesses 'vote yes' for a hardfork by applying it to their servers. It will only take effect if 17/21 witnesses (including the 20 primary and one backup) vote yes.
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 ?
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