From: Cameron Garnham <da2ce7@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Exploring Network Rule Changes
Date: Thu, 20 Apr 2017 20:02:43 +0300 [thread overview]
Message-ID: <45C4F619-5BAF-4D84-8759-8D6BC5C63FC3@gmail.com> (raw)
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
reply other threads:[~2017-04-20 17:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45C4F619-5BAF-4D84-8759-8D6BC5C63FC3@gmail.com \
--to=da2ce7@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox