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
186
187
188
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A458949D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 22:31:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com
[209.85.213.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05D2CEA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 22:30:59 +0000 (UTC)
Received: by iggf3 with SMTP id f3so144585684igg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 15:30:59 -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:to
:cc:content-type;
bh=oG9G+Ta8OeKfliGLWd9t022Q3qwh3ymijQ6COs0d37w=;
b=L5z1aNcflxXAHhG3u3+O0LFyMJ0BG1KaV6/tzEXevlQJOUlQG9hAuO1RcG8K2HIZH6
qEcfp2sPbYMep0yfXEzgDakXtt7toOq2utlePUUahOk7+HmCCsYDSBNwf3qsRcF3CyG5
cOMtNij0I/hu51qK97PcOZXWdVLh0V6mcEXhwbQdRUvQGoM3a9+HCm9XX2uJPBA6qm3V
UGvP/OBtxfQhuIvzr9sDrMYLSbfhI/Prlc28eOnWCIHcwQzOE0HW0e+vJSBWAC/3BYWI
cG6w8Ut/P4Yph+0xD6t3IHCPgANQ7ICVle7rNEr8ov0DJfp0KtLNby6UfDWM45GjPBip
+f2w==
MIME-Version: 1.0
X-Received: by 10.107.168.145 with SMTP id e17mr8757571ioj.112.1437604259507;
Wed, 22 Jul 2015 15:30:59 -0700 (PDT)
Received: by 10.79.38.79 with HTTP; Wed, 22 Jul 2015 15:30:59 -0700 (PDT)
In-Reply-To: <CA+w+GKTfBNsQm0X27+QeMmLvJXuX0H=8+ij_GU6mkGnWn-poZA@mail.gmail.com>
References: <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
<CAPg+sBgugLSVEwDLXhgey86_rM2fTjGWXFuXsiZioJKCZiHiNg@mail.gmail.com>
<CA+w+GKTfBNsQm0X27+QeMmLvJXuX0H=8+ij_GU6mkGnWn-poZA@mail.gmail.com>
Date: Wed, 22 Jul 2015 15:30:59 -0700
Message-ID: <CADm_WcZkhWs23t4sJZ0AQm1wU+eOiKbWFo5decU018NJH9TNQw@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a1142e4fc373511051b7e532e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
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: Wed, 22 Jul 2015 22:31:00 -0000
--001a1142e4fc373511051b7e532e
Content-Type: text/plain; charset=UTF-8
I wouldn't go quite that far. The reality is somewhere in the middle, as
Bryan Cheng noted in this thread:
Quoting BC,
> Upgrading to a version of Bitcoin Core that is incompatible with your
ideals is in no way a forced choice, as you have stated in your email;
forks, alternative clients, or staying on an older version are all valid
choices. If the majority of the network chooses not to endorse a specific
change, then the majority of the network will continue to operate just fine
without it, and properly structured consensus rules will pull the minority
along as well.
The developers *propose* a new version, by publishing a new release. The
individual network nodes choose to accept or reject that.
So I respectfully disagree with "core devs don't control the network" and
"core devs control the network" both.
There are checks-and-balances that make the system work. Consensus is most
strongly measured by user actions after software release. If the
developers fail to reflect user consensus, the network will let us know.
On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
>> Bitcoin Core is not running the Bitcoin economy, and its developers have
>> no authority to set its rules.
>>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make
> a release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1142e4fc373511051b7e532e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wouldn't go quite that far.=C2=A0 The reality is som=
ewhere in the middle, as Bryan Cheng noted in this thread:<div><br></div><d=
iv>Quoting BC,</div><div><span style=3D"font-size:13px">> Upgrading to a=
version of Bitcoin Core that is incompatible with your ideals is in no way=
a forced choice, as you have stated in your email; forks, alternative clie=
nts, or staying on an older version are all valid choices. If the majority =
of the network chooses not to endorse a specific change, then the majority =
of the network will continue to operate just fine without it, and properly =
structured consensus rules will pull the minority along as well.</span><br>=
</div><div><span style=3D"font-size:13px"><br></span></div><div><span style=
=3D"font-size:13px">The developers <i>propose</i>=C2=A0a new version, by pu=
blishing a new release.=C2=A0 The individual network nodes choose to accept=
or reject that.</span></div><div><span style=3D"font-size:13px"><br></span=
></div><div><span style=3D"font-size:13px">So I respectfully disagree with =
"core devs don't control the network" and "core devs con=
trol the network" both.</span><br></div><div><span style=3D"font-size:=
13px"><br></span></div><div><div><span style=3D"font-size:13px">There are c=
hecks-and-balances that make the system work.=C2=A0 Consensus is most stron=
gly measured by user actions after software release.=C2=A0 If the developer=
s fail to reflect user consensus, the network will let us know.</span></div=
><div><span style=3D"font-size:13px"><br></span></div><div><span style=3D"f=
ont-size:13px"><br></span></div><div><span style=3D"font-size:13px"><br></s=
pan></div><div><span style=3D"font-size:13px"><br></span></div><div><span s=
tyle=3D"font-size:13px"><br></span></div></div><div><span style=3D"font-siz=
e:13px"><br></span></div><div><span style=3D"font-size:13px"><br></span></d=
iv><div><span style=3D"font-size:13px"><br></span></div><div><span style=3D=
"font-size:13px"><br></span></div><div><span style=3D"font-size:13px"><br><=
/span></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev <span dir=3D"l=
tr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">Hi Pieter,<div><br></div><div>I=
think a core area of disagreement is this:<br><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
p dir=3D"ltr">Bitcoin Core is not running the Bitcoin economy, and its deve=
lopers have no authority to set its rules. </p></blockquote></span><div>In =
fact Bitcoin Core is running the Bitcoin economy, and its developers do hav=
e the authority to set its rules. This is enforced by the reality of ~100% =
market share and limited github commit access.</div><div><br></div><div>You=
may not like this situation, but it is what it is. By refusing to make a r=
elease with different rules, people who disagree are faced with only two op=
tions:</div><div><br></div><div>1. Swallow it even if they hate it</div><di=
v>2. Fork the project and fork the block chain with it (XT)</div><div><br><=
/div><div>There are no alternatives. People who object to (2) are inherentl=
y suggesting (1) is the only acceptable path, which not surprisingly, makes=
a lot of people very angry.</div></div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--001a1142e4fc373511051b7e532e--
|
