multi: Add forced deployment result network param. #3060
Merged
Conversation
This file contains 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
davecgh
added
the
test coverage
davecgh
force-pushed
the
multi_always_active_forced_choice_deployment_flag
branch
3 times, most recently
from
e0aeb31 to
bf8764f
Compare
davecgh
force-pushed
the
multi_always_active_forced_choice_deployment_flag
branch
3 times, most recently
from
148e0e7 to
5982282
Compare
jholdstock
reviewed
Feb 25, 2023
davecgh
force-pushed
the
multi_always_active_forced_choice_deployment_flag
branch
from
5982282 to
3559b0c
Compare
Not a bad idea. I don't see any way it could realistically be exploited short of modifying the code (which one could always do anyway) because there are no CLI options or anything to control it, but it's good to be paranoid about such things. I've added a check during chain initialization to reject it. |
jholdstock
approved these changes
Feb 26, 2023
Currently, the lack of an entry for a given deployment in the chain parameters for a given network is treated the same as the deployment being active. This behavior is primarily in order to support testing without needing to go through the entire voting process on testing networks such as the simulation network as well as allows rule changes on newer versions of testnet networks that were previously accepted on prior versions. However, the existing approach has been pointed out on several occasions as being surprising behavior by those working on new consensus changes and it also means testing the voting process itself for new rule changes prior to their release requires a cumbersome sequence of not so obvious steps. Further, it also makes those historical pruned rule changes invisible to RPCs like getblockchaininfo. In order to address the aforementioned inconveniences, this adds a new parameter to the per-network chain parameters to specify a vote choice that should always be considered as having been the majority result of a vote and updates the relevant logic in blockchain accordingly to respect it. The new approach does not suffer from the aforementioned inconveniences as it permits a simple single line modification to allow the voting process to be tested as well as makes automatically activated historical rules visible to the RPCs like getblockchaininfo. Finally, this also adds previously pruned deployment parameters back to the relevant network parameters with the new field set to force them to be active.
davecgh
force-pushed
the
multi_always_active_forced_choice_deployment_flag
branch
from
3559b0c to
5218eb1
Compare
JoeGruffins
approved these changes
Feb 27, 2023
davecgh
deleted the
multi_always_active_forced_choice_deployment_flag
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This requires #3059.Currently, the lack of an entry for a given deployment in the chain parameters for a given network is treated the same as the deployment being active. This behavior is primarily in order to support testing without needing to go through the entire voting process on testing networks such as the simulation network as well as allows rule changes on newer versions of
testnetnetworks that were previously accepted on prior versions.However, the existing approach has been pointed out on several occasions as being surprising behavior by those working on consensus changes and it also means testing the voting process itself for new rule changes prior to their release requires a cumbersome sequence of not so obvious steps. Further, it also makes those historical pruned rule changes invisible to RPCs like
getblockchaininfo.In order to address the aforementioned inconveniences, this adds a new parameter to the per-network chain parameters to specify a vote choice that should always be considered as having been the majority result of a vote and updates the relevant logic in blockchain accordingly to respect it.
The new approach does not suffer from the aforementioned inconveniences as it permits a simple single line modification to allow the voting process to be tested as well as makes automatically activated historical rules visible to the RPCs like
getblockchaininfo.Finally, this also adds previously pruned deployment parameters back to the relevant network parameters with the new field set to force them to be active.
Closes #3058.