[bitcoin-dev] Exploring Network Rule Changes

[Cameron Garnham <da2ce7@gmail.com>]

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