1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
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=
|
