Return-Path: <da2ce7@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 96500480
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Apr 2017 17:02:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f67.google.com (mail-lf0-f67.google.com
	[209.85.215.67])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8068246
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Apr 2017 17:02:53 +0000 (UTC)
Received: by mail-lf0-f67.google.com with SMTP id 88so6462947lfr.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 20 Apr 2017 10:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:content-transfer-encoding:mime-version:subject:message-id:date
	:to; bh=SvIGsGJa4FZP3GlRHflz7wpsFqfSjaSY1w/fq1c757U=;
	b=ZENhK8/dJLs/uK12vOWDZrj8h3FfOwRRGecGFTREZfjYjPO2CW1tYk0LDxFgkwVRD2
	bUnL++Za1IGz+jtVhdMSKJUsQGE4kqcqpLIBHWFPUBBpK/VVNG2Xx5BfTDZWVnrxkZWT
	KF+RrVULny+e7CuEcG+gSbgiJn+yc2f105p9bWrBs28VpLyYX0kaUhbBE5iOFH152Cda
	E09V/apQowwx8vcAYE1RV0p9tXuO10+id+tvYewOMbBo0iqo7ub/1zv3RM1eMcM98igs
	CDZ+YsbsNAvYjYsDJLYl97gpi7CjoW9fhW9w4VZLjzcbxbSl9Guz6kOZsacV8sIEd+t2
	LigQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:content-transfer-encoding:mime-version
	:subject:message-id:date:to;
	bh=SvIGsGJa4FZP3GlRHflz7wpsFqfSjaSY1w/fq1c757U=;
	b=CRSHfb3ImWZEtg3D2y+PKuy8mTylKkmo0eD4S+/C+Tc/hjJAvIz3LGzfF3UZPaLZSc
	Ze9f9harSMsK2w58R50Mt06iaQWKo4P4+ldwEmlArncAeb4V2fbW0W77MLiehwiCwTx6
	uCSjyhMrFe6u1M86ZPt/C28+fgCtT84cLfW/m3KefMPPbyhhqSJmRKdTL0Tr9Dhn9emj
	KYFkyv+MLHX/kLy0geaysddLoA7KUvFqIF8F54h639DaiqLTxPBuwceeuxk1P+IZ1LJQ
	bx8DmJblFWWFDTjrkWhhmuJeL5paXk80SDl3OKbYYFPY4GyCbRs9TWKXIfbaq9GLgBrc
	S2Uw==
X-Gm-Message-State: AN3rC/5XFcdzq9/6uFqa8ICH9mrtL8Uy11NprUDBq+6/8DyeuCrJIlsS
	79qnO93lAko+0iaWy5s=
X-Received: by 10.25.221.18 with SMTP id u18mr2849773lfg.64.1492707771769;
	Thu, 20 Apr 2017 10:02:51 -0700 (PDT)
Received: from [10.0.1.37] ([91.204.212.210])
	by smtp.gmail.com with ESMTPSA id x1sm1131528lfb.37.2017.04.20.10.02.50
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 20 Apr 2017 10:02:50 -0700 (PDT)
From: Cameron Garnham <da2ce7@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <45C4F619-5BAF-4D84-8759-8D6BC5C63FC3@gmail.com>
Date: Thu, 20 Apr 2017 20:02:43 +0300
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Exploring Network Rule Changes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Apr 2017 17:02:54 -0000

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. (=E2=80=9CEvil=E2=80=9D, 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=E2=80=99t 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:  =E2=80=9CS1M=
ON".  And BIP 148 (SegWit) as:  =E2=80=9CS1UFN=E2=80=9D.  However this =
letter code is just for fun. :)

Cameron=