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
216
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Z5eTV-0003Gx-I0
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 18:23:41 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.54 as permitted sender)
client-ip=209.85.215.54; envelope-from=gavinandresen@gmail.com;
helo=mail-la0-f54.google.com;
Received: from mail-la0-f54.google.com ([209.85.215.54])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5eTU-00065k-97
for bitcoin-development@lists.sourceforge.net;
Thu, 18 Jun 2015 18:23:41 +0000
Received: by lacny3 with SMTP id ny3so59791568lac.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 18 Jun 2015 11:23:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.204.40 with SMTP id kv8mr13861169lac.113.1434651813862;
Thu, 18 Jun 2015 11:23:33 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Thu, 18 Jun 2015 11:23:33 -0700 (PDT)
In-Reply-To: <CAPWm=eX5Oc4QXkp3H5thPBPzJ-t7JGzF5pVaP+eSd0=h52ku=A@mail.gmail.com>
References: <55828737.6000007@riseup.net>
<CANEZrP3M7+BsZKLFZV-0A_fC7NmMGbTDxsx3ywru3dSW78ZskQ@mail.gmail.com>
<20150618111407.GA6690@amethyst.visucore.com>
<CAPg+sBj_go==m6-++sA53imYdz4OLH4bkyiuAyEM8YR8CaTd=w@mail.gmail.com>
<CAJHLa0OKXaUD6MnN4N6RGbNwrXx43jBm9MiELQK6BRw1OL3HNA@mail.gmail.com>
<0ede5c200ce70e4d92541dd91749b4ea@riseup.net>
<CAJHLa0NiDamkrbW2TMoTLqMPhzw0LBboNp1+_atBGDYMa135uw@mail.gmail.com>
<e6da277c39b0354cdf24361e20a1fce2@riseup.net>
<CAPWm=eX5Oc4QXkp3H5thPBPzJ-t7JGzF5pVaP+eSd0=h52ku=A@mail.gmail.com>
Date: Thu, 18 Jun 2015 14:23:33 -0400
Message-ID: <CABsx9T1ENeoZ968PDGUgBPdZLmkwRCDtBvZ2BwT0HaFdWxSL3g@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Alex Morcos <morcos@gmail.com>
Content-Type: multipart/alternative; boundary=001a11347da6bde4a00518cee74e
X-Spam-Score: 1.1 (+)
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
(gavinandresen[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
1.7 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z5eTU-00065k-97
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Justus Ranvier <justusranvier@riseup.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 18:23:41 -0000
--001a11347da6bde4a00518cee74e
Content-Type: text/plain; charset=UTF-8
On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos <morcos@gmail.com> wrote:
> Let me take a pass at explaining how I see this.
>
> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
> the decider but he works under a process that is well understood by
> developers on the project in which he takes under reasonable consideration
> other technical opinions and prefers to have clear agreement among them.
>
Yes.
2) Changes to the consensus rules: As others have said, this isn't anyone's
> decision for anyone else.
>
Yes.
> It's up to each individual user as to what code they run and what rules
> they enforce. So then why is everyone so up in arms about what Mike and
> Gavin are proposing if everyone is free to decide for themselves? I
> believe that each individual user should adhere to the principle that there
> should be no changes to the consensus rules unless there is near complete
> agreement among the entire community, users, developers, businesses miners
> etc. It is not necessary to define complete agreement exactly because every
> individual person decides for themselves. I believe that this is what
> gives Bitcoin, or really any money, its value and what makes it work, that
> we all agree on exactly what it is. So I believe that it is misleading and
> bad for Bitcoin to tell users and business that you can just choose without
> concern for everyone else which code you'll run and we'll see which one
> wins out. No. You should run the old consensus rules (on any codebase you
> want) until you believe that pretty much everyone has consented to a change
> in the rules. It is your choice, but I think a lot of people that have
> spent time thinking about the philosophy of consensus systems believe that
> when the users of the system have this principle in mind, it's what will
> make the system work best.
>
I don't think I agree with "pretty much everybody", because status-quo bias
is a very powerful thing. Any change that disrupts the way they've been
doing things will generate significant resistance -- there will be 10 or
20% of any population that will take a position of "too busy to think about
this, everything seems to be working great, I don't like change, NO to any
change."
For example, I think some of the resistance for bigger blocks is coming
from contributors who are worried they, personally, won't be able to keep
up with a bigger blockchain. They might not be able to run full nodes from
their home network connections (or might not be able to run a full node AND
stream Game of Thrones), on their old raspberry pi machines.
The criteria for me is "clear super-majority of the people and businesses
who are using Bitcoin the most," and I think that criteria is met.
> 3) Code changes to Core that do change consensus: I think that Wladimir,
> all the other committers besides Gavin, and almost all of the other
> developers on Core would defer to #2 above and wait for its outcome to be
> clear before considering such a code change.
>
Yes, that's the way it has mostly been working. But even before stepping
down as Lead I was starting to wonder if there are ANY successful open
source projects that didn't have either a Benevolent Dictator or some clear
voting process to resolve disputes that cannot be settled with "rough
consensus."
--
--
Gavin Andresen
--001a11347da6bde4a00518cee74e
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 18, 2015 at 1:42 PM, Alex Morcos <span dir=3D"ltr"><<a href=3D"m=
ailto:morcos@gmail.com" target=3D"_blank">morcos@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Let me take a pass=
at explaining how I see this.<div><br></div><div>1) Code changes to Bitcoi=
n Core that don't change consensus: =C2=A0Wladimir is the decider but h=
e works under a process that is well understood by developers on the projec=
t in which he takes under reasonable consideration other technical opinions=
and prefers to have clear agreement among them.</div></div></blockquote><d=
iv><br></div><div>Yes.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr"><div>2) Changes to the consensus rules: As others have said=
, this isn't anyone's decision for anyone else.</div></div></blockq=
uote><div><br></div><div>Yes.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>It's up to each individual user as to wha=
t code they run and what rules they enforce.=C2=A0 So then why is everyone =
so up in arms about what Mike and Gavin are proposing if everyone is free t=
o decide for themselves?=C2=A0 I believe that each individual user should a=
dhere to the principle that there should be no changes to the consensus rul=
es unless there is near complete agreement among the entire community, user=
s, developers, businesses miners etc. It is not necessary to define complet=
e agreement exactly because every individual person decides for themselves.=
=C2=A0 I believe that this is what gives Bitcoin, or really any money, its =
value and what makes it work, that we all agree on exactly what it is.=C2=
=A0 So I believe that it is misleading and bad for Bitcoin to tell users an=
d business that you can just choose without concern for everyone else which=
code you'll run and we'll see which one wins out.=C2=A0 No.=C2=A0 =
You should run the old consensus rules (on any codebase you want) until you=
believe that pretty much everyone has consented to a change in the rules.=
=C2=A0 It is your choice, but I think a lot of people that have spent time =
thinking about the philosophy of consensus systems believe that when the us=
ers of the system have this principle in mind, it's what will make the =
system work best.</div></div></blockquote><div><br></div><div>I don't t=
hink I agree with "pretty much everybody", because status-quo bia=
s is a very powerful thing. Any change that disrupts the way they've be=
en doing things will generate significant resistance -- there will be 10 or=
20% of any population that will take a position of "too busy to think=
about this, everything seems to be working great, I don't like change,=
NO to any change."</div><div><br></div><div>For example, I think some=
of the resistance for bigger blocks is coming from contributors who are wo=
rried they, personally, won't be able to keep up with a bigger blockcha=
in. They might not be able to run full nodes from their home network connec=
tions (or might not be able to run a full node AND stream Game of Thrones),=
on their old raspberry pi machines.</div><div><br></div><div>The criteria =
for me is "clear super-majority of the people and businesses who are u=
sing Bitcoin the most," and I think that criteria is met.</div><div><b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>3) Code changes to Core that do change consensus: I think that Wladimir,=
all the other committers besides Gavin, and almost all of the other develo=
pers on Core would defer to #2 above and wait for its outcome to be clear b=
efore considering such a code change.<br></div></div></blockquote><div><br>=
</div><div>Yes, that's the way it has mostly been working. But even bef=
ore stepping down as Lead I was starting to wonder if there are ANY success=
ful open source projects that didn't have either a Benevolent Dictator =
or some clear voting process to resolve disputes that cannot be settled wit=
h "rough consensus."</div></div><br clear=3D"all"><div><br></div>=
-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--001a11347da6bde4a00518cee74e--
|
