I have taken some time to think about consensus systems in-general; and write up a guide that explores the problems space of changing the rules of such systems.
Hopefully, this guide will clarify the different options available to the Bitcoin Community. I am posting this to the Bitcoin Development mailing list for review. Possibly a more comprehensive form of this document could be useful as an informative BIP. ** Type of Change ** There are three categories of changes: S: Addition of a new Rule. (Soft-Fork) H: Removal of an old Rule. (Hard-Fork) E: Subverting an old Rule. (“Evil”, Non-Traditional Soft-Fork) * Addition of a new Rule: All previous rules in the system remain enforced as originally intended. There are two sub-categories for the addition of a new rule: 1: New Functionally is added to the system, without effecting old use cases. (Opt-In New Functionality) 2: Functional users of the system must change their behaviour to suit the new rule. (Mandatory New Functionality) * Removal of an old Rule Equivalent replacing the entire system with any-new system. All full-users of the system must migrate to the new system. * Subverting an old Rule New Functionally is added that explicitly Replaces Old Functionality. Users must upgrade and migrate to the new Functionally to continue using the system. ** Type of Activation ** There are two types of activations: U. External Activations. (User Activated) M. Internal Activations. (Miner Activated, PoS Activated, Internal Governance Model, etc) It is possible to have more than one Activation Strategy used concurrently. * External Activations These Activations are dictated by facts that are not quantifiable from within the System. Generally, this will be a set-of-users, external to the system, that come to their own agreement to change the system. * Internal Activations These activations use some metric from within the system to determine if a proposed change is activated. Generally, some sort of internal signalling or vetoing process will happen and based upon its results, will dictate the if the change is activated. ** Type of Signalling ** Users within the system with more important roles may wish to (or be forced to) signal or (not) veto about a particular topic. This could be part of the activation strategy (internal activations), or just simply to quantify the support of the upcoming change. There are two core types of Signalling: O: Optional F. Forced There are two styles of Signalling: N. Normal Signalling (Opt-In) V. Veto (Opt-Out) * Optional Signalling Orthogonal to the system rules; however, the signalling still may affect other system rules. * Enforced Signalling This is a meta-rule change. Normally only temporally enforced upon the system. This rule change doesn’t directly affect the core behaviour of the system; it is just used for meta-purposes in the scope of another rule change. * Normal Signalling Passive Behaviour signals no support. * Veto Signalling Passive Behaviour signals support. If I have missed anything or if anything is not clear, please contact me. PS. For example, you could call a BIP9 (SegWit) activation as a: “S1MON". And BIP 148 (SegWit) as: “S1UFN”. However this letter code is just for fun. :) Cameron _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
