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 RuleEquivalent replacing the entire system with any-new system. All full-users of the system must migrate to the new system.

* Subverting an old RuleNew Functionally is added that explicitly Replaces Old Functionality.

Users must upgrade and migrate to the new Functionally to continue using the system.

It is possible to have more than one Activation Strategy used concurrently.

* External ActivationsThese 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 ActivationsThese 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: OptionalF. Forced

There are two styles of Signalling:

N. Normal Signalling (Opt-In)V. Veto (Opt-Out)

* Optional SignallingOrthogonal to the system rules; however, the signalling still may affect other system rules.

* Enforced SignallingThis 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 SignallingPassive Behaviour signals no support.

* Veto SignallingPassive 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. :)