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
189
190
191
192
193
194
195
196
197
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z5ZvF-0005YB-Uu
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 13:32:01 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.43 as permitted sender)
client-ip=74.125.82.43; envelope-from=mh.in.england@gmail.com;
helo=mail-wg0-f43.google.com;
Received: from mail-wg0-f43.google.com ([74.125.82.43])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5ZvE-0007ON-Cy
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 13:32:01 +0000
Received: by wgfq1 with SMTP id q1so17195631wgf.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 06:31:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.209.130 with SMTP id mm2mr15420375wjc.64.1434634314368;
Thu, 18 Jun 2015 06:31:54 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Thu, 18 Jun 2015 06:31:54 -0700 (PDT)
In-Reply-To: <20150618111407.GA6690@amethyst.visucore.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
<20150618111407.GA6690@amethyst.visucore.com>
Date: Thu, 18 Jun 2015 15:31:54 +0200
X-Google-Sender-Auth: AEzoNtA1xpEgIJFqFVDAuWfmLFs
Message-ID: <CANEZrP2iMXeL-5zyE2cvoyNRakhZbQfLXORZ2AhqEATQE-KjAQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3a82e2b0cc7e0518cad43e
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z5ZvE-0007ON-Cy
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
to Remove Commit Access from Other Developers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2015 13:32:02 -0000
--047d7b3a82e2b0cc7e0518cad43e
Content-Type: text/plain; charset=UTF-8
OK, let's agree to unpack the two things.
The first issue is how are decisions made in Bitcoin Core? I struggle to
explain this to others because I don't understand it myself. Is it a vote
of people with commit access? Is it a 100% agreement of "core developers"
and if so, who are these people? Is it "whoever reverts the change last"?
Could I write down in a document a precise description of how decisions are
made? No, and that's been a fairly frustrating problem for a long time.
But let's leave it to one side for a moment.
Let's focus on the other issue: what happens if the Bitcoin Core decision
making process goes wrong?
For the sake of argument let's pretend we're discussing a different change,
let's imagine there is a proposal to change the block format to include a
Widget, where a Widget is some potentially desirable thing. And this change
means a hard fork. Let's put the block size to one side for a second to
avoid getting distracted.
Imagine that 90% of people in Bitcoin want their Widgets, but one of your
committers refuses to accept it. I am not saying the block size debate has
such proportions but pretend Widgets do.
What is the process for resolving this problem?
Gavin and I say - there is a process, and that process is a hard fork of
the block chain.
What you're saying is - there is no process because a contentious hard fork
must never happen. Such a change is simply impossible.
Now which is a better description of this situation? Is the "it must never
happen end of story" really the cuddly warm democracy that you seem to
suggest? Or is it more like a dictatorship where the opinions of one or two
people can override all the others?
The typical answer I'm seeing to this is that Bitcoin Core's own decision
making process is so fantastic that it never goes wrong, even though
"consensus" is not defined and "technical majority" is not defined and we
have serious long time contributors on this mailing list (such as wallet
developers) disagreeing with this consensus yet our feedback is being
ignored.
You guys *must* accept that your preferred process for resolving disputes
is, itself, in dispute. That leaves the block chain itself as the only
remaining method for bringing this saga to a close.
So this is why we keep disagreeing:
- If Bitcoin Core has reached a formal decision made by the maintainer
via whatever mechanism he likes to not accept the block size increase, then
alright, technical disputes will happen. But ....
- You should agree that the next step is a fork of both the software and
the block chain. And you should welcome such a thing because it is the ONLY
check on your own power. It's the one thing that allows the community to
reject the decision making process you are using in case it goes wrong.
I keep reading that Bitcoin cannot survive a hard fork. Well, we've
survived an accidental fork that happened without anyone being prepared,
and even with a planned soft fork "never upgrade" isn't really an option
for either miners or businesses, so ultimately node operators must know
about upgrades and make them. Both myself and Gavin think this process can
work out OK.
Do you at least understand where we're coming from here, even if you
disagree? And if you disagree, is it because you think a hard fork to
resolve a dispute can't work technically, or is it some other reason?
--047d7b3a82e2b0cc7e0518cad43e
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"><div=
>OK, let's agree to unpack the two things.</div><div><br></div><div>The=
first issue is how are decisions made in Bitcoin Core? I struggle to expla=
in this to others because I don't understand it myself. Is it a vote of=
people with commit access? Is it a 100% agreement of "core developers=
" and if so, who are these people? Is it "whoever reverts the cha=
nge last"?=C2=A0 Could I write down in a document a precise descriptio=
n of how decisions are made? No, and that's been a fairly frustrating p=
roblem for a long time.</div><div><br></div><div>But let's leave it to =
one side for a moment.</div><div><br></div><div>Let's focus on the othe=
r issue: =C2=A0 what happens if the Bitcoin Core decision making process go=
es wrong?=C2=A0</div><div><br></div><div>For the sake of argument let's=
pretend we're discussing a different change, let's imagine there i=
s a proposal to change the block format to include a Widget, where a Widget=
is some potentially desirable thing. And this change means a hard fork. Le=
t's put the block size to one side for a second to avoid getting distra=
cted.</div><div><br></div><div>Imagine that 90% of people in Bitcoin want t=
heir Widgets, but one of your committers refuses to accept it.=C2=A0 I am n=
ot saying the block size debate has such proportions but pretend Widgets do=
.</div><div><br></div><div>What is the process for resolving this problem?<=
/div><div><br></div><div>Gavin and I say - there is a process, and that pro=
cess is a hard fork of the block chain.</div><div><br></div><div>What you&#=
39;re saying is - there is no process because a contentious hard fork must =
never happen. Such a change is simply impossible.</div><div><br></div><div>=
Now which is a better description of this situation? Is the "it must n=
ever happen end of story" really the cuddly warm democracy that you se=
em to suggest? Or is it more like a dictatorship where the opinions of one =
or two people can override all the others?</div><div><br></div><div>The typ=
ical answer I'm seeing to this is that Bitcoin Core's own decision =
making process is so fantastic that it never goes wrong, even though "=
consensus" is not defined and "technical majority" is not de=
fined and we have serious long time contributors on this mailing list (such=
as wallet developers) disagreeing with this consensus yet our feedback is =
being ignored.</div><div><br></div><div>You guys <i>must</i>=C2=A0accept th=
at your preferred process for resolving disputes is, itself, in dispute. Th=
at leaves the block chain itself as the only remaining method for bringing =
this saga to a close.</div><div><br></div><div>So this is why we keep disag=
reeing:</div><div><ul><li>If Bitcoin Core has reached a formal decision mad=
e by the maintainer via whatever mechanism he likes=C2=A0to not accept the =
block size increase, then alright, technical disputes will happen. But ....=
<br><br></li><li>You should agree that the next step is a fork of both the =
software and the block chain. And you should welcome such a thing because i=
t is the ONLY check on your own power. It's the one thing that allows t=
he community to reject the decision making process you are using in case it=
goes wrong.</li></ul><div>I keep reading that Bitcoin cannot survive a har=
d fork. Well, we've survived an accidental fork that happened without a=
nyone being prepared, and even with a planned soft fork "never upgrade=
" isn't really an option for either miners or businesses, so ultim=
ately node operators must know about upgrades and make them. Both myself an=
d Gavin think this process can work out OK.</div><div><br></div><div>Do you=
at least understand where we're coming from here, even if you disagree=
? And if you disagree, is it because you think a hard fork to resolve a dis=
pute can't work technically, or is it some other reason?</div></div></d=
iv></div></div>
--047d7b3a82e2b0cc7e0518cad43e--
|
