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
|
Return-Path: <jameson.lopp@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6383EE12
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 02:06:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com
[209.85.217.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 443F7A9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 02:06:10 +0000 (UTC)
Received: by mail-lb0-f170.google.com with SMTP id cs9so36682889lbb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 18:06:10 -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=uWrZL1OHOwyWOyclbQua+XzuMzpLWAW2aH5u6S0+mTw=;
b=s5flOBmD4b0W43OFZpHpkqpj9uGT9hIMq6lTW4YKU3FjHdC6Akrz6AGTuGkneH+hdS
V6P/QKXB0n1WCbidc2QY11TRAMwab4azU5nbFv+G/pDWHA7KghpWw1CTzL0BQs0+4U4w
VbqQ6LWcjVIk5kMECpEqB69WXzEZpIVrNhELrB8voG7OMVr1FXXdu9N5/GPAkQPW5Tpz
thWHW0wjFX67LqZj6DX6KkwMbXMQaLepxiDFbK5c4lO08B0UhS7YykjiA1MuB2K8v6mB
8bf779os8xsUiwVlwYOw/sW1HRc4LhBABRYzns0z34eaOLwGT2aLh/BvO/yEUIX/MgiA
1gOA==
MIME-Version: 1.0
X-Received: by 10.112.166.33 with SMTP id zd1mr16797992lbb.113.1450317968312;
Wed, 16 Dec 2015 18:06:08 -0800 (PST)
Received: by 10.25.21.228 with HTTP; Wed, 16 Dec 2015 18:06:08 -0800 (PST)
In-Reply-To: <CAPg+sBimfFVea4Sorgx=DaMPVs1k1DrmTA2ZFdLFtxrqKm23-w@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
<CADm_Wcae7OK7kyXkfh+7XFrc2WYsv7T1Va3_E=5om+XYrL9pOw@mail.gmail.com>
<CAPg+sBimfFVea4Sorgx=DaMPVs1k1DrmTA2ZFdLFtxrqKm23-w@mail.gmail.com>
Date: Wed, 16 Dec 2015 18:06:08 -0800
Message-ID: <CADL_X_eWNuMJn_UBm3YYg_HjHmyDj3J85xp02L-0N-x6bmPZLA@mail.gmail.com>
From: Jameson Lopp <jameson.lopp@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c37c5450116c05270e77cd
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, 17 Dec 2015 12:33:58 +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: Thu, 17 Dec 2015 02:06:11 -0000
--001a11c37c5450116c05270e77cd
Content-Type: text/plain; charset=UTF-8
On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 10:08 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
> >> 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.
> >
> >
> > This circles back to Problem #1: Avoidance of a choice is a still a
> choice
> > - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
> Economic
> > Change Event risk.
>
> We are not avoiding a choice. We don't have the authority to make a choice.
>
> > And #3: If the likely predicted course is that Bitcoin Core will not
> accept
> > a protocol change changing MAX_BLOCK_SIZE via hard fork in the short
> term,
> > the core dev team should communicate that position clearly to users and
> > media.
>
> I indeed think we can communicate much better that deciding consensus
> rules is not within our power.
>
Indeed, because I sometimes find these statements to be confusing as well -
I can completely understand what you mean if you're speaking from a moral
standpoint. If you're saying that it's unacceptable for the Bitcoin Core
developers to force consensus changes upon the system, I agree. But
thankfully the design of the system does not allow the developers to do so.
Developers can commit amazing code or terrible code, but it must be
voluntarily adopted by the rest of the ecosystem. Core developers can't
decide these changes, they merely propose them to the ecosystem by writing
and releasing code.
I agree that Core developers have no authority to make these decisions on
behalf of all of the network participants. However, they are in a position
of authority when it comes to proposing changes. One of my takeaways from
Hong Kong was that most miners have little interest in taking
responsibility for consensus changes - they trust the Core developers to
use their expertise to propose changes that will result in the continued
operation of the network and not endanger their business operations.
A non-trivial portion of the ecosystem is requesting that the Core
developers make a proposal so that the network participants can make a
choice. Jeff noted that we can expect for the economic conditions of the
network to change significantly in 2016, barring higher throughput
capacity. If the year+ deployment timeframe for hard forks proposed by Matt
on another thread is what we can expect for any proposed consensus change,
then it should be non-contentious to announce that there will be no hard
fork in 2016. This will give clarity to the rest of the ecosystem as to how
they should prepare.
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11c37c5450116c05270e77cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Dec 16, 2015 at 1:11 PM, Pieter Wuille via bitcoin-dev <span di=
r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><span class=3D"">On Wed, Dec 16, 2015 at 1=
0:08 PM, Jeff Garzik <<a href=3D"mailto:jgarzik@gmail.com">jgarzik@gmail=
.com</a>> wrote:<br>
>> You present this as if the Bitcoin Core development team is in cha=
rge<br>
>> of deciding the network consensus rules, and is responsible for ma=
king<br>
>> changes to it in order to satisfy economic demand. If that is the<=
br>
>> case, Bitcoin has failed, in my opinion.<br>
><br>
><br>
> This circles back to Problem #1:=C2=A0 =C2=A0Avoidance of a choice is =
a still a choice<br>
> - failing to ACK a MAX_BLOCK_SIZE increase still creates very real Eco=
nomic<br>
> Change Event risk.<br>
<br>
</span>We are not avoiding a choice. We don't have the authority to mak=
e a choice.<br>
<span class=3D""><br>
> And #3:=C2=A0 If the likely predicted course is that Bitcoin Core will=
not accept<br>
> a protocol change changing MAX_BLOCK_SIZE via hard fork in the short t=
erm,<br>
> the core dev team should communicate that position clearly to users an=
d<br>
> media.<br>
<br>
</span>I indeed think we can communicate much better that deciding consensu=
s<br>
rules is not within our power.<br></blockquote><div><br></div><div>Indeed, =
because I sometimes find these statements to be confusing as well - I can c=
ompletely understand what you mean if you're speaking from a moral stan=
dpoint. If you're saying that it's unacceptable for the Bitcoin Cor=
e developers to force consensus changes upon the system, I agree. But thank=
fully the design of the system does not allow the developers to do so. Deve=
lopers can commit amazing code or terrible code, but it must be voluntarily=
adopted by the rest of the ecosystem. Core developers can't decide the=
se changes, they merely propose them to the ecosystem by writing and releas=
ing code.=C2=A0</div><div><br></div><div>I agree that Core developers have =
no authority to make these decisions on behalf of all of the network partic=
ipants. However, they are in a position of authority when it comes to propo=
sing changes. One of my takeaways from Hong Kong was that most miners have =
little interest in taking responsibility for consensus changes - they trust=
the Core developers to use their expertise to propose changes that will re=
sult in the continued operation of the network and not endanger their busin=
ess operations.</div><div><br></div><div>A non-trivial portion of the ecosy=
stem is requesting that the Core developers make a proposal so that the net=
work participants can make a choice. Jeff noted that we can expect for the =
economic conditions of the network to change significantly in 2016, barring=
higher throughput capacity. If the year+ deployment timeframe for hard for=
ks proposed by Matt on another thread is what we can expect for any propose=
d consensus change, then it should be non-contentious to announce that ther=
e will be no hard fork in 2016. This will give clarity to the rest of the e=
cosystem as to how they should prepare.</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5"><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>
</div></div></blockquote></div><br></div></div>
--001a11c37c5450116c05270e77cd--
|
