HIP36 proposal: use blockheights instead of time#257
Merged
jamiew merged 6 commits intohelium:masterfrom Aug 12, 2021
Merged
Conversation
Contributor
|
Thanks for your submission, will review! |
Contributor
|
Numbered and merging. Please tag tracking issue #260 for future PRs. For anyone with questions or comments on this HIP, please also use the tracking issue #260 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
At the time of writing, most (if not all) blockchain variables and implementations are activated manually by the Helium team, requiring active intervention from the team and have a time-based activation. The active intervention can, for the greatest part, be avoided by enabling auto-activation of variables at certain blockheights. This has been the standard for most blockchain projects. One example is the bi-yearly halving of HNT rewards agreed to in HIP20 which should be integrated with blockheights rather than be defined by moment in time for its activation - and in the future, hopefully any change of blockchain variables can be defined that way.
This HIP does not contain a complete schedule for HIP20, but does contain all variables needed to properly create the schedule (last halving at block 964732 and increments of 1051200 blocks per halving).
Rendered view: https://github.com/Bx64/HIP/blob/master/0036-blockheights-instead-of-time.md