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
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Z5Yx4-0008UD-4G
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 12:29:50 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.175 as permitted sender)
client-ip=209.85.217.175; envelope-from=pieter.wuille@gmail.com;
helo=mail-lb0-f175.google.com;
Received: from mail-lb0-f175.google.com ([209.85.217.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5Yx2-0006g4-IY
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 12:29:50 +0000
Received: by lbbvz5 with SMTP id vz5so3086865lbb.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 05:29:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.44.225 with SMTP id h1mr12705119lam.5.1434630582199;
Thu, 18 Jun 2015 05:29:42 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Thu, 18 Jun 2015 05:29:42 -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 14:29:42 +0200
Message-ID: <CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: "Wladimir J. van der Laan" <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=089e0160b7be3c6df70518c9f696
X-Spam-Score: -0.6 (/)
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
(pieter.wuille[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1Z5Yx2-0006g4-IY
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 12:29:50 -0000
--089e0160b7be3c6df70518c9f696
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan <laanwj@gmail.com>
wrote:
> Like in any open source project there is lots of decision making ability
> for code changes. I'd say look at the changelog for e.g. 0.11
> https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
> or follow pull requests for a while, to see how many decisions about
> changes are made from day to day. No, I'm not sitting on my hands, and so
> is none of the other contributors that you'd like to get rid of.
>
The analogy goes further even. Even though I disagree with some of the
changes you're making, I respect Mike's (and anyone's) right to make a fork
of Bitcoin Core. That's how open source works: if people disagree with
changes made or not made, they can maintain their own version. However:
> Consensus changes are *much* more difficult, on the other hand. Even
> relatively straightforward softforks come with a long discussion process
> (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone
> needs to upgrade their software!), and simply not possible if almost the
> entire technical community disagrees with you.
>
Consensus changes - in particular hardforks - are not about making a change
to the software. You are effectively asking users of the system to migrate
to a new system. Perhaps one which is a philosophical successor to the old
one, but a different system, with new rules that are incompatible with the
old one.
I believe this is something that can only be done if there is no
controversy about the change, for different reasons:
* Risk: no matter how you determine the switchover date, there is no way of
knowing when (and whether at all) everyone changes their full nodes (and
perhaps other software), and even very high hash power votes cannot prevent
an actual fork from appearing afterwards. At best, people lose the
guarantee that their confirmations are meaningful (because at some point it
becomes clear that the other side will get adopted, and they need to
switch). At worst, a fork persists, and two partitions appear, in each of
which you can spend every pre-existing coin. This defeats the primary
purpose Bitcoin was designed for: double spend protection.
* Philosophy: Bitcoin is not a democracy. The full node security model is
designed to minimize trust in other parties in the system. This works by
validating as much as possible according to the consensus rules. In
particular, there is no "majority vote" that can override things (contrary
to what some people think, it is not "longest chain wins, and a majority of
miners decide"; even a majority of miners cannot steal your coins or
produce more than the allowed subsidy, unless they convince others to
change their software). Changing the rules should be possible if there is
wide consensus, but nobody should feel forced to change their code against
their will.
* Governance: being able to push for a controversial change to the system
sets an incredibly dangerous precedent about who is in charge of the
system's rules. What if next time it is a change demanded by parties with
less good intentions (and yes, I believe people in this discussions all
have good intentions to improve the system in a way they think is most
useful)? I can promise you that I will say anything in mail to this list if
someone points a gun at me, and I think you should make the same assumption
about other people here. By avoiding controversial changes, you avoid
external and potentially invisible manipulation.
Of course, sometimes changes to the consensus rules may be wanted. The
presence of a bug is a good reason, and widespread agreement about one of
the system's limitation is too. As I said before, I think technological
growth in network bandwidth, processing power, and storage, are a good
reason why the system should be able to scale proportionally. I think there
are good technical and economic reasons why we should be cautious about
this, but the primary requirement is consensus, and aligning people's
expectation about what they can expect from network's evolution.
--
Pieter
--089e0160b7be3c6df70518c9f696
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan =
<span dir=3D"ltr"><<a href=3D"mailto:laanwj@gmail.com" target=3D"_blank"=
>laanwj@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Like in any open sourc=
e project there is lots of decision making ability for code changes. I'=
d say look at the changelog for e.g. 0.11 <a href=3D"https://github.com/bit=
coin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/0.11/doc/rel=
ease-notes.md#0110-change-log</a>, or follow pull requests for a while, to =
see how many decisions about changes are made from day to day. No, I'm =
not sitting on my hands, and so is none of the other contributors that you&=
#39;d like to get rid of.<br></blockquote><div><br></div><div>The analogy g=
oes further even. Even though I disagree with some of the changes you'r=
e making, I respect Mike's (and anyone's) right to make a fork of B=
itcoin Core. That's how open source works: if people disagree with chan=
ges made or not made, they can maintain their own version. However:<br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Consensus changes are *much* more difficult, on the other hand. Even relati=
vely straightforward softforks come with a long discussion process (see BIP=
62, BIP66). A hardfork is hard to do at the best of times (everyone needs t=
o upgrade their software!), and simply not possible if almost the entire te=
chnical community disagrees with you.<br></blockquote><div><br></div><div>C=
onsensus changes - in particular hardforks - are not about making a change =
to the software. You are effectively asking users of the system to migrate =
to a new system. Perhaps one which is a philosophical successor to the old =
one, but a different system, with new rules that are incompatible with the =
old one.<br><br></div><div>I believe this is something that can only be don=
e if there is no controversy about the change, for different reasons:<br></=
div><div><br>* Risk: no matter how you determine the switchover date, there=
is no way of knowing when (and whether at all) everyone changes their full=
nodes (and perhaps other software), and even very high hash power votes ca=
nnot prevent an actual fork from appearing afterwards. At best, people lose=
the guarantee that their confirmations are meaningful (because at some poi=
nt it becomes clear that the other side will get adopted, and they need to =
switch). At worst, a fork persists, and two partitions appear, in each of w=
hich you can spend every pre-existing coin. This defeats the primary purpos=
e Bitcoin was designed for: double spend protection.<br><br></div><div>* Ph=
ilosophy: Bitcoin is not a democracy. The full node security model is desig=
ned to minimize trust in other parties in the system. This works by validat=
ing as much as possible according to the consensus rules. In particular, th=
ere is no "majority vote" that can override things (contrary to w=
hat some people think, it is not "longest chain wins, and a majority o=
f miners decide"; even a majority of miners cannot steal your coins or=
produce more than the allowed subsidy, unless they convince others to chan=
ge their software). Changing the rules should be possible if there is wide =
consensus, but nobody should feel forced to change their code against their=
will.<br><br></div><div>* Governance: being able to push for a controversi=
al change to the system sets an incredibly dangerous precedent about who is=
in charge of the system's rules. What if next time it is a change dema=
nded by parties with less good intentions (and yes, I believe people in thi=
s discussions all have good intentions to improve the system in a way they =
think is most useful)? I can promise you that I will say anything in mail t=
o this list if someone points a gun at me, and I think you should make the =
same assumption about other people here. By avoiding controversial changes,=
you avoid external and potentially invisible manipulation.<br><br></div><d=
iv>Of course, sometimes changes to the consensus rules may be wanted. The p=
resence of a bug is a good reason, and widespread agreement about one of th=
e system's limitation is too. As I said before, I think technological g=
rowth in network bandwidth, processing power, and storage, are a good reaso=
n why the system should be able to scale proportionally. I think there are =
good technical and economic reasons why we should be cautious about this, b=
ut the primary requirement is consensus, and aligning people's expectat=
ion about what they can expect from network's evolution.<br><br>-- <br>=
</div><div>Pieter<br><br></div></div></div></div>
--089e0160b7be3c6df70518c9f696--
|
