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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B267AC2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 20:05:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
[209.85.220.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1FA8C1A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 20:05:41 +0000 (UTC)
Received: by qkei195 with SMTP id i195so6088434qke.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2015 13:05:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:cc
:content-type; bh=QGApVFcZ4Z9Ptkbx7xcaGRBFlW/CnGipEcx/8lYsync=;
b=YRoOiP+2s2xRlCtDLE9XcoiANeL9CXGXUoni1J7bucEFxZ0SAF5vmpKJH3HPslmdYo
FYfy74eS25ul/3E5yC2MTUr95J8k7bjek0hb+mQJeJdoCr7PoZvGOHIm6qYZCQucOdVD
SfXDJ2GVc2yZBUGw1VfIvWlxEJlp62wwy8EwlxKeJ8GQJU0pR69MkAquII1/8suS2lyr
hSwk64jZJsK0+Z/aCyio3T/tAAuYE3mknHVh16ZsRdT8i69dy4Th4uT57sNrN/px7PBH
MwpEfE9LILvrZ0mUn1os6Cek+nRGGT5Li6TJAi/4AFMboOOeNgVimADLFefyCFzxcUa4
m0/Q==
MIME-Version: 1.0
X-Received: by 10.140.216.208 with SMTP id m199mr65424830qhb.69.1435262740380;
Thu, 25 Jun 2015 13:05:40 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Thu, 25 Jun 2015 13:05:40 -0700 (PDT)
In-Reply-To: <CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
References: <COL402-EAS109000AAC490BCF2DD69116CDAF0@phx.gbl>
<558B4632.8080504@bitcoins.info>
<CAOG=w-sxovqy0kDyBX=cx4CWWb=cd_F5bO3iH8ZBHsa0D_uK+A@mail.gmail.com>
Date: Thu, 25 Jun 2015 21:05:40 +0100
Message-ID: <CAE-z3OVOr=1e=_05Amzb9_JY70Zr+J5_ZTKArUzCFS2jPDAGHA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135d796ccc2e605195d253f
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP Process and Votes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 25 Jun 2015 20:05:42 -0000
--001a1135d796ccc2e605195d253f
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> I'm sorry but this is absolutely not the case, Milly. The reason that
> people get defensive is that we have a carefully constructed process that
> does work (thank you very much!) and is well documented.
>
There is no process for handling hard forks, which aren't bug fixes.
Soft forks have a defined process of something like
- BIP proposal + discussion
- Proposed code
- Dev acceptance
- Release
- Miner vote/acceptance
The devs have a weak veto. If they refuse to move forward with changes,
miners could perform a soft fork on their own. They don't want to do that,
as it would be controversial and the devs know the software better.
The miner veto is stronger (for soft forks) but not absolute. The devs
could checkpoint/blacklist a chain if miners implemented a fork that wasn't
acceptable (assuming the community backed them).
When ASICs arrived, it was pointed out by some that the devs could hit back
if ASICs weren't made publicly available. If they slightly tweaked the
hashing algorithm, then current generation of ASICs would be useless. The
potential threat may have acted as a disincentive for ASIC manufacturers to
use the ASICs themselves.
Moving forward with agreement between all involved is the recommended and
desirable approach.
Consensus between all parties is the goal but isn't absolutely required.
This escape valve is partly what makes consensus work. If you dig your
heels in, then the other side can bypass you, but they have an incentive to
try to convince you to compromise first. The outcome is better if a middle
ground can be found.
Hard forks are different. The "checks and balances" of weak vetoes are not
present. This means that things can devolve from consensus to mutual
veto. Consensus ceases to be a goal and becomes a requirement.
This is partly a reflection of the nature of hard forks. Everyone needs to
upgrade. On the other hand, if most of the various groups upgrade, then
users of the legacy software would have to upgrade or get left behind. If
5% of the users decided not to upgrade, should they be allowed to demand
that nobody else does?
There is clearly some kind of threshold that is reasonable.
The fundamental problem is that there isn't agreement on what the block
size is. Is it equal in status to the 21 million BTC limit?
If Satoshi had said that 1MB was part of the definition of Bitcoin, then I
think people would accept it to the same extent as they accept the 21
million coin limit. It might cause people to leave the coin though.
It was intended to be temporary, but people have realized that it might be
a good idea to keep it. In effect both sides could argue that they should
be considered the status quo.
I wonder if a coin toss would be acceptable :). "Come to an agreement or
we decide by coin toss"
--001a1135d796ccc2e605195d253f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jun 25, 2015 at 2:50 AM, Mark Friedenbach <span dir=3D"ltr"><<a href=
=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px=
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div><div><div>I'm sorry but this is absolutely not the c=
ase, Milly. The reason that people get defensive is that we have a carefull=
y constructed process that does work (thank you very much!) and is well doc=
umented. </div></div></div></div></blockquote><div><br></div><div>There is =
no process for handling hard forks, which aren't bug fixes.<br><br></di=
v><div>Soft forks have a defined process of something like<br></div><div><b=
r>- BIP proposal + discussion<br></div><div>- Proposed code<br></div><div>-=
Dev acceptance<br></div><div>- Release<br></div><div>- Miner vote/acceptan=
ce<br><br></div><div>The devs have a weak veto.=C2=A0 If they refuse to mov=
e forward with changes, miners could perform a soft fork on their own.=C2=
=A0 They don't want to do that, as it would be controversial and the de=
vs know the software better.<br><br></div><div>The miner veto is stronger (=
for soft forks) but not absolute.=C2=A0 The devs could checkpoint/blacklist=
a chain if miners implemented a fork that wasn't acceptable (assuming =
the community backed them).<br><br></div><div>When ASICs arrived, it was po=
inted out by some that the devs could hit back if ASICs weren't made pu=
blicly available.=C2=A0 If they slightly tweaked the hashing algorithm, the=
n current generation of ASICs would be useless.=C2=A0=C2=A0 The potential t=
hreat may have acted as a disincentive for ASIC manufacturers to use the AS=
ICs themselves.<br></div><div><br></div><div>Moving forward with agreement =
between all involved is the recommended and desirable approach.<br><br></di=
v><div>Consensus between all parties is the goal but isn't absolutely r=
equired.=C2=A0 This escape valve is partly what makes consensus work.=C2=A0=
If you dig your heels in, then the other side can bypass you, but they hav=
e an incentive to try to convince you to compromise first.=C2=A0 The outcom=
e is better if a middle ground can be found.<br><br></div><div>Hard forks a=
re different.=C2=A0 The "checks and balances" of weak vetoes are =
not present.=C2=A0 This means that things can devolve from consensus to mut=
ual veto.=C2=A0 Consensus ceases to be a goal and becomes a requirement.<br=
><br></div><div>This is partly a reflection of the nature of hard forks.=C2=
=A0 Everyone needs to upgrade.=C2=A0 On the other hand, if most of the vari=
ous groups upgrade, then users of the legacy software would have to upgrade=
or get left behind.=C2=A0 If 5% of the users decided not to upgrade, shoul=
d they be allowed to demand that nobody else does?<br><br></div><div>There =
is clearly some kind of threshold that is reasonable.<br><br></div><div>The=
fundamental problem is that there isn't agreement on what the block si=
ze is.=C2=A0 Is it equal in status to the 21 million BTC limit?<br><br>If S=
atoshi had said that 1MB was part of the definition of Bitcoin, then I thin=
k people would accept it to the same extent as they accept the 21 million c=
oin limit.=C2=A0 It might cause people to leave the coin though.<br><br></d=
iv><div>It was intended to be temporary, but people have realized that it m=
ight be a good idea to keep it.=C2=A0 In effect both sides could argue that=
they should be considered the status quo.<br><br></div><div>I wonder if a =
coin toss would be acceptable :).=C2=A0 "Come to an agreement or we de=
cide by coin toss"<br></div></div></div></div>
--001a1135d796ccc2e605195d253f--
|
