spelling and grammar corrections #3
Open
Conversation
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
adamjonas
commented
Jun 17, 2020
| * Allowing proposed soft forks to fail to activate in the event of significant reasonable objections: for example, if someone has a well-accepted, reasonable use of Bitcoin that is working today, and reasonably expects it to continue working well into the future, a soft fork that breaks that use case should not be activated. | ||
| * Using hashpower-based enforcement to reduce the risk of chain splits or consensus divergence. Because some node operators will not immediately deploy new software releases, it is expected that a significant minority of nodes will not enforce proposed rule changes for an extended period after a new soft fork is proposed for activation. If a supermajority of hashpower is enforcing the soft fork rules, the likelihood of a chain split that does not comply with the soft fork rules remaining the most work chain becomes extremely low, which allows earler activation of the soft fork to remain safe. | ||
| * Using hashpower-based enforcement to reduce the risk of chain splits or consensus divergence. Because some node operators will not immediately deploy new software releases, it is expected that a significant minority of nodes will not enforce proposed rule changes for an extended period after a new soft fork is proposed for activation. If a supermajority of hashpower is enforcing the soft fork rules, the likelihood of a chain split that does not comply with the soft fork rules remaining the most work chain becomes extremely low, which allows earlier activation of the soft fork to remain safe. |
adamjonas
commented
Jun 17, 2020
| Two activation modes are supported: conditional and guaranteed. | ||
|
|
||
| In conditional activation<ref>'''Why support conditional activation?''' Conditional activation allows soft forks to fail (one of the process goals), and also allows earlier activation provided there is sufficient hashpower-based enforcement of the soft fork rules (another of the process goals).</ref> the soft fork has a single primary signalling phase, beginning at the specified start height and continuing for the specified number of periods. If the threshold of signalling blocks is met in any period during the primary phase, the soft fork locks in, otherwise it fails. In this case, the quiet and secondary periods parameters are not used.<ref>'''How does conditional activation differ from BIP9?''' Conditional activation occurs in much the same way as [[bip-0009.mediawiki|BIP9]], with the exception that phase transitions are specified by height rather than mediantime. This provides greater predictability, as it is always clear how many signalling blocks are possible; and slightly simplifies the implementation as there are fewer special cases where states may be missed due to unusual timestamp behaviour.</ref> | ||
| In conditional activation<ref>'''Why support conditional activation?''' Conditional activation allows soft forks to fail (one of the process goals), and also allows earlier activation provided there is sufficient hashpower-based enforcement of the soft fork rules (another of the process goals).</ref> the soft fork has a single primary signalling phase, beginning at the specified start height and continuing for the specified number of periods. If the threshold of signalling blocks is met in any period during the primary phase, the soft fork locks in, otherwise it fails. In this case, the quiet and secondary periods parameters are not used.<ref>'''How does conditional activation differ from BIP9?''' Conditional activation occurs in much the same way as [[bip-0009.mediawiki|BIP9]], with the exception that phase transitions are specified by height rather than mediantime. This provides greater predictability, as it is always clear how many signalling blocks are possible and slightly simplifies the implementation as there are fewer special cases where states may be missed due to unusual timestamp behaviour.</ref> |
adamjonas
commented
Jun 17, 2020
| In conditional activation<ref>'''Why support conditional activation?''' Conditional activation allows soft forks to fail (one of the process goals), and also allows earlier activation provided there is sufficient hashpower-based enforcement of the soft fork rules (another of the process goals).</ref> the soft fork has a single primary signalling phase, beginning at the specified start height and continuing for the specified number of periods. If the threshold of signalling blocks is met in any period during the primary phase, the soft fork locks in, otherwise it fails. In this case, the quiet and secondary periods parameters are not used.<ref>'''How does conditional activation differ from BIP9?''' Conditional activation occurs in much the same way as [[bip-0009.mediawiki|BIP9]], with the exception that phase transitions are specified by height rather than mediantime. This provides greater predictability, as it is always clear how many signalling blocks are possible and slightly simplifies the implementation as there are fewer special cases where states may be missed due to unusual timestamp behaviour.</ref> | ||
|
|
||
| In guaranteed activation<ref>'''Why support guaranteed activation?''' Guaranteed activation is provided as a fallback method in case there is wide support for activation, and no reasonable objections against it, but supermajority hashpower enforcement is not achieved via conditional activation. If hashpower enforcement does not become available, a long timeframe is provided to ensure all bar a small minority of nodes will have been able to upgrade, in line with the first process goal (high levels of node adoption). This provides an alternative to other approaches to avoiding reliance on hashpower support such as [[bip-0008.mediawiki|BIP8]] or [[bip-0148.mediawiki|BIP148]] or [[bip-0091.mediawiki||BIP91]]</ref><ref>'''How does guaranteed activation differ from BIP8?''' A significant drawback of [[bip-0008.mediawiki|BIP8]] is that no failure path exists -- any soft fork with [[bip-0008.mediawiki|BIP8]] parameters defined will eventually activate.</ref><ref>'''How does guaranteed activation differ from BIP148 and BIP91?''' [[bip-0148.mediawiki|BIP148]] and [[bip-0091.mediawiki|BIP91]] provided for activation of the [[bip-0009.mediawiki|BIP9]] segwit deployment by forcing miners to signal for its activation. This intentionally risked the possibility of orphaning blocks that failed to follow these new BIPs, with the possible result of small chainsplits and risks of doublespends as a result. This conflicts with final process goal above (retaining hashpower).</ref> the soft fork undergoes three phases: the primary signalling phase, a quiet phase, and the secondary signalling phase. The primary phase precisely overlaps the primary phase of conditional activation, and if the threshold is passed during the phase, the soft fork locks in occurs in exactly the same way. Otherwise, after the primary signalling phase ends, a quiet phase begins, during which signalling is ignored<ref>'''Why have a quiet phase?''' In the event that conditional activation fails, but there are no reasonable objections to activation, then it may take some time for node operators to either override their node software's activation setting (from conditional to guaranteed), or to upgrade their node software to a newer version where the deployment uses guaranteed activation by default. If activation by a supermajority of hashpower were to occur before a majority of nodes were updated, the soft fork rules may not be enforced consistently, creating a higher risk of temporary chain splits or other problems. Providing a dedicated quiet period for these updates to take place is intended to reduce that risk.</ref>, and following that a secondary signalling phase begins. During the secondary signalling phase, if the threshold is passed in a particular period, the soft fork locks in then, otherwise the soft fork locks in at the end of the secondary phase. With guaranteed activation, the soft fork is not able to fail. | ||
| In guaranteed activation<ref>'''Why support guaranteed activation?''' Guaranteed activation is provided as a fallback method in case there is widespread support for activation, and no reasonable objections against it, but supermajority hashpower enforcement is not achieved via conditional activation. If hashpower enforcement does not become available, a long timeframe is provided to ensure all but a small minority of nodes will have been able to upgrade, in line with the first process goal (high levels of node adoption). This provides an alternative to other approaches to avoiding reliance on hashpower support such as [[bip-0008.mediawiki|BIP8]] or [[bip-0148.mediawiki|BIP148]] or [[bip-0091.mediawiki||BIP91]]</ref><ref>'''How does guaranteed activation differ from BIP8?''' A significant drawback of [[bip-0008.mediawiki|BIP8]] is that no failure path exists -- any soft fork with [[bip-0008.mediawiki|BIP8]] parameters defined will eventually activate.</ref><ref>'''How does guaranteed activation differ from BIP148 and BIP91?''' [[bip-0148.mediawiki|BIP148]] and [[bip-0091.mediawiki|BIP91]] provided for activation of the [[bip-0009.mediawiki|BIP9]] segwit deployment by forcing miners to signal for its activation. This intentionally risked the possibility of orphaning blocks that failed to follow these new BIPs, with the possible result of small chainsplits and risks of doublespends as a result. This conflicts with the final process goal above (retaining hashpower).</ref> the soft fork undergoes three phases: the primary signalling phase, a quiet phase, and the secondary signalling phase. The primary phase precisely overlaps the primary phase of conditional activation, and if the threshold is passed during the phase, the soft fork lock in occurs in exactly the same way. Otherwise, after the primary signalling phase ends, a quiet phase begins, during which signalling is ignored<ref>'''Why have a quiet phase?''' In the event that conditional activation fails, but there are no reasonable objections to activation, then it may take some time for node operators to either override their node software's activation setting (from conditional to guaranteed), or to upgrade their node software to a newer version where the deployment uses guaranteed activation by default. If activation by a supermajority of hashpower were to occur before a majority of nodes were updated, the soft fork rules may not be enforced consistently, creating a higher risk of temporary chain splits or other problems. Providing a dedicated quiet period for these updates to take place is intended to reduce that risk.</ref>, and following that a secondary signalling phase begins. During the secondary signalling phase, if the threshold is passed in a particular period, the soft fork locks in then, otherwise the soft fork locks in at the end of the secondary phase. With guaranteed activation, the soft fork is not able to fail. |
adamjonas
commented
Jun 17, 2020
| In guaranteed activation<ref>'''Why support guaranteed activation?''' Guaranteed activation is provided as a fallback method in case there is widespread support for activation, and no reasonable objections against it, but supermajority hashpower enforcement is not achieved via conditional activation. If hashpower enforcement does not become available, a long timeframe is provided to ensure all but a small minority of nodes will have been able to upgrade, in line with the first process goal (high levels of node adoption). This provides an alternative to other approaches to avoiding reliance on hashpower support such as [[bip-0008.mediawiki|BIP8]] or [[bip-0148.mediawiki|BIP148]] or [[bip-0091.mediawiki||BIP91]]</ref><ref>'''How does guaranteed activation differ from BIP8?''' A significant drawback of [[bip-0008.mediawiki|BIP8]] is that no failure path exists -- any soft fork with [[bip-0008.mediawiki|BIP8]] parameters defined will eventually activate.</ref><ref>'''How does guaranteed activation differ from BIP148 and BIP91?''' [[bip-0148.mediawiki|BIP148]] and [[bip-0091.mediawiki|BIP91]] provided for activation of the [[bip-0009.mediawiki|BIP9]] segwit deployment by forcing miners to signal for its activation. This intentionally risked the possibility of orphaning blocks that failed to follow these new BIPs, with the possible result of small chainsplits and risks of doublespends as a result. This conflicts with the final process goal above (retaining hashpower).</ref> the soft fork undergoes three phases: the primary signalling phase, a quiet phase, and the secondary signalling phase. The primary phase precisely overlaps the primary phase of conditional activation, and if the threshold is passed during the phase, the soft fork lock in occurs in exactly the same way. Otherwise, after the primary signalling phase ends, a quiet phase begins, during which signalling is ignored<ref>'''Why have a quiet phase?''' In the event that conditional activation fails, but there are no reasonable objections to activation, then it may take some time for node operators to either override their node software's activation setting (from conditional to guaranteed), or to upgrade their node software to a newer version where the deployment uses guaranteed activation by default. If activation by a supermajority of hashpower were to occur before a majority of nodes were updated, the soft fork rules may not be enforced consistently, creating a higher risk of temporary chain splits or other problems. Providing a dedicated quiet period for these updates to take place is intended to reduce that risk.</ref>, and following that a secondary signalling phase begins. During the secondary signalling phase, if the threshold is passed in a particular period, the soft fork locks in then, otherwise the soft fork locks in at the end of the secondary phase. With guaranteed activation, the soft fork is not able to fail. | ||
|
|
||
| Implementations should always default to conditional activation when the deployment attempt begins. Later releases of the implementation (particularly ones mades near to, during, or after the quiet period) may change the default to guaranteed activation provided that no reasonable objections to the proposal have been uncovered, and there is continued support for activation<ref>'''How should developers decide to switch the default to guaranteed activation?''' The criteria for switching to guaranteed activation by default is intended to be based on obvious, relatively objective criteria: by the time the primary phase ends, it should be obvious if there are any reasonable objections, and whether there is any remaining support for activation. This is in line with the proposal's major philosophical goal of avoiding centralisation: with obvious, objective criteria anyone can reasonably be expected to come to the same conclusion, so developers are not put in a privileged position, and furthermore because the activation mode is only a default, it should be easy for the default to be changed back, either directly by users, or by other developers creating a fork.</ref>. Implementations should also allow users to override the default from conditional activation to guaranteed implementation, so that the soft fork rules can be enforced without needing to upgrade to a newer software version. | ||
| Implementations should always default to conditional activation when the deployment attempt begins. Later releases of the implementation (particularly ones made near to, during, or after the quiet period) may change the default to guaranteed activation provided that no reasonable objections to the proposal have been uncovered, and there is continued support for activation<ref>'''How should developers decide to switch the default to guaranteed activation?''' The criteria for switching to guaranteed activation by default is intended to be based on obvious, relatively objective criteria: by the time the primary phase ends, it should be obvious if there are any reasonable objections, and whether there is any remaining support for activation. This is in line with the proposal's major philosophical goal of avoiding centralisation: with obvious, objective criteria anyone can reasonably be expected to come to the same conclusion, so developers are not put in a privileged position, and furthermore because the activation mode is only a default, it should be easy for the default to be changed back, either directly by users, or by other developers creating a fork.</ref>. Implementations should also allow users to override the default from conditional activation to guaranteed implementation, so that the soft fork rules can be enforced without needing to upgrade to a newer software version. |
adamjonas
commented
Jun 17, 2020
| # The '''secondary_periods''' should be 52 (two years for mainnet and testnet) | ||
| A later deployment using the same bit is possible as long as its ''start_height'' is greater than the prior deployment's final height, that is ''start_height + period * (primary_periods + quiet_periods + secondary_periods + 3)'', or ''start_height + period * (primary_periods + 3)'' if it is clear that guaranteed activation is not in use. Reuse is discouraged until it is necessary, and even then it is recommended to have a pause in between to allow detection of buggy software that may be continuing to signal for the prior deployment. | ||
| A later deployment using the same bit is possible as long as its ''start_height'' is greater than the prior deployment's final height, that is ''start_height + period * (primary_periods + quiet_periods + secondary_periods + 3)'', or ''start_height + period * (primary_periods + 3)'' if it is clear that guaranteed activation is not in use. Reuse is discouraged until it is necessary, and even then, it is recommended to have a pause in between to allow detection of buggy software that may be continuing to signal for the prior deployment. |
Author
There was a problem hiding this comment.
and even then -> and even then,
ajtowns
pushed a commit
that referenced
this pull request
Nov 14, 2024
Update OP_CAT implementation code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The highlighting the diff is terrible so left some comments where it wasn't obvious.