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
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
Return-Path: <voisine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A240111EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2015 06:26:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com
[209.85.213.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69344148
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 Dec 2015 06:26:12 +0000 (UTC)
Received: by mail-ig0-f172.google.com with SMTP id mv3so62258837igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 Dec 2015 22:26:12 -0800 (PST)
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=4MwlufsQsghMkzhe/ZPVlOvqq8DmBvUwV1UDz4tn65I=;
b=bUZuC2berpErwj4VIKk2RF2QuJORFM92HR/WuHXhCdUlOAMFqOHdKUN6uVOeUXtcPE
UbuWKGO6diHvKOsCV9rtOaENJagYZsuJZjX1BaL+SRRICq9dRyf8vDQvpLrIyoEM3cm7
R8XCBaR3fP4G4d6ZT0P9y2UXlwE1H65uezD7yWsAtORojdJz8PryLHNVJZgThvH2aa7f
MdNm2OMvRhGxwOofZKDUiuiKr51Y/6Odny41rskVUdWCvbts7lhwBBlFEMaxz59/Ucwl
9rM9KF00GuNdYESImONe7DB3m+WYlpi9aldUH06SwvimCWPxIBl5E6qbXfzLX4B6byLQ
XO5A==
MIME-Version: 1.0
X-Received: by 10.50.65.39 with SMTP id u7mr29170453igs.85.1450851971901; Tue,
22 Dec 2015 22:26:11 -0800 (PST)
Received: by 10.36.22.148 with HTTP; Tue, 22 Dec 2015 22:26:11 -0800 (PST)
In-Reply-To: <CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
Date: Tue, 22 Dec 2015 22:26:11 -0800
Message-ID: <CACq0ZD7PEL4ZaUndvtPOfar=MXp4hwUZfu2xQ_Fph6dOVPLV5w@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b2e145568309705278accd1
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
X-Mailman-Approved-At: Thu, 24 Dec 2015 11:21:52 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation &
moral hazard
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, 23 Dec 2015 06:26:13 -0000
--047d7b2e145568309705278accd1
Content-Type: text/plain; charset=UTF-8
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for
> making changes to it in order to satisfy economic demand. If that is
> the case, Bitcoin has failed, in my opinion.
Pieter, what's actually happening is that the bitcoin-core release has
become a Schelling point in the consensus game:
https://en.wikipedia.org/wiki/Schelling_point
Due to the strong incentives for consensus, everyone is looking for an
obvious reference point that they think everyone else will also pick, even
though the point itself isn't critical, only that everyone agree on
whatever point is picked. Like it or not, the bitcoin-core release, and by
extension it's committers have a great degree of influence over what the
community as a whole decides to do. If core screws things up badly enough,
yes, the community will settle on some other focal point for consensus, but
the cost and risk of doing so is high, so there is indeed unavoidable moral
hazard for whoever has control over any such focus point.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > 2) If block size stays at 1M, the Bitcoin Core developer team should
> sign a
> > collective note stating their desire to transition to a new economic
> policy,
> > that of "healthy fee market" and strongly urge users to examine their fee
> > policies, wallet software, transaction volumes and other possible User
> > impacting outcomes.
>
> You present this as if the Bitcoin Core development team is in charge
> of deciding the network consensus rules, and is responsible for making
> changes to it in order to satisfy economic demand. If that is the
> case, Bitcoin has failed, in my opinion.
>
> What the Bitcoin Core team should do, in my opinion, is merge any
> consensus change that is uncontroversial. We can certainly -
> individually or not - propose solutions, and express opinions, but as
> far as maintainers of the software goes our responsibility is keeping
> the system running, and risking either a fork or establishing
> ourselves as the de-facto central bank that can make any change to the
> system would greatly undermine the system's value.
>
> Hard forking changes require that ultimately every participant in the
> system adopts the new rules. I find it immoral and dangerous to merge
> such a change without extremely widespread agreement. I am personally
> fine with a short-term small block size bump to kick the can down the
> road if that is what the ecosystem desires, but I can only agree with
> merging it in Core if I'm convinced that there is no strong opposition
> to it from others.
>
> Soft forks on the other hand only require a majority of miners to
> accept them, and everyone else can upgrade at their leisure or not at
> all. Yes, old full nodes after a soft fork are not able to fully
> validate the rules new miners enforce anymore, but they do still
> verify the rules that their operators opted to enforce. Furthermore,
> they can't be prevented. For that reason, I've proposed, and am
> working hard, on an approach that includes Segregated Witness as a
> first step. It shows the ecosystem that something is being done, it
> kicks the can down the road, it solves/issues half a dozen other
> issues at the same time, and it does not require the degree of
> certainty needed for a hardfork.
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--047d7b2e145568309705278accd1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> You present this as if the Bitcoin Core development t=
eam is in charge<br>> of deciding the network consensus rules, and is re=
sponsible for<div>> making=C2=A0changes to it in order to satisfy econom=
ic demand. If that is</div><div>> the=C2=A0case, Bitcoin has failed, in =
my opinion.<br><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">Pieter, what's actually happening is that the bitcoin-core release =
has become a Schelling point in the consensus game:</div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra"><a href=3D"https://en.wikiped=
ia.org/wiki/Schelling_point">https://en.wikipedia.org/wiki/Schelling_point<=
/a><br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
">Due to the strong incentives for consensus, everyone is looking for an ob=
vious reference point that they think everyone else will also pick, even th=
ough the point itself isn't critical, only that everyone agree on whate=
ver point is picked. Like it or not, the bitcoin-core release, and by exten=
sion it's committers have a great degree of influence over what the com=
munity as a whole decides to do. If core screws things up badly enough, yes=
, the community will settle on some other focal point for consensus, but th=
e cost and risk of doing so is high, so there is indeed unavoidable moral h=
azard for whoever has control over any such focus point.</div><div class=3D=
"gmail_extra"><div><div class=3D"gmail_signature"><div dir=3D"ltr"><div><di=
v dir=3D"ltr"><div><div dir=3D"ltr"><div><br>Aaron Voisine</div><div>co-fou=
nder and CEO<br><a href=3D"http://breadwallet.com" target=3D"_blank">breadw=
allet</a></div></div></div></div></div></div></div></div>
<br><div class=3D"gmail_quote">On Wed, Dec 16, 2015 at 10:34 AM, Pieter Wui=
lle via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><span class=3D"">On Wed, Dec=
16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> 2) If block size stays at 1M, the Bitcoin Core developer team should s=
ign a<br>
> collective note stating their desire to transition to a new economic p=
olicy,<br>
> that of "healthy fee market" and strongly urge users to exam=
ine their fee<br>
> policies, wallet software, transaction volumes and other possible User=
<br>
> impacting outcomes.<br>
<br>
</span>You present this as if the Bitcoin Core development team is in charg=
e<br>
of deciding the network consensus rules, and is responsible for making<br>
changes to it in order to satisfy economic demand. If that is the<br>
case, Bitcoin has failed, in my opinion.<br>
<br>
What the Bitcoin Core team should do, in my opinion, is merge any<br>
consensus change that is uncontroversial. We can certainly -<br>
individually or not - propose solutions, and express opinions, but as<br>
far as maintainers of the software goes our responsibility is keeping<br>
the system running, and risking either a fork or establishing<br>
ourselves as the de-facto central bank that can make any change to the<br>
system would greatly undermine the system's value.<br>
<br>
Hard forking changes require that ultimately every participant in the<br>
system adopts the new rules. I find it immoral and dangerous to merge<br>
such a change without extremely widespread agreement. I am personally<br>
fine with a short-term small block size bump to kick the can down the<br>
road if that is what the ecosystem desires, but I can only agree with<br>
merging it in Core if I'm convinced that there is no strong opposition<=
br>
to it from others.<br>
<br>
Soft forks on the other hand only require a majority of miners to<br>
accept them, and everyone else can upgrade at their leisure or not at<br>
all. Yes, old full nodes after a soft fork are not able to fully<br>
validate the rules new miners enforce anymore, but they do still<br>
verify the rules that their operators opted to enforce. Furthermore,<br>
they can't be prevented. For that reason, I've proposed, and am<br>
working hard, on an approach that includes Segregated Witness as a<br>
first step. It shows the ecosystem that something is being done, it<br>
kicks the can down the road, it solves/issues half a dozen other<br>
issues at the same time, and it does not require the degree of<br>
certainty needed for a hardfork.<br>
<span class=3D""><font color=3D"#888888"><br>
--<br>
Pieter<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>
</font></span></blockquote></div><br></div></div></div>
--047d7b2e145568309705278accd1--
|
