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
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
|
Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EE611B38
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2017 06:13:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com
[209.85.213.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 19184148
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2017 06:13:36 +0000 (UTC)
Received: by mail-vk0-f42.google.com with SMTP id x75so169616720vke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 22:13:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=W46JZKifx/nB6GgWct+upRd0S2VgG26cKbgSp+ldtZ4=;
b=R2YBQppUBz2RyEeGy4Lb8Y9oo61U/jCHnKTNkt1eidkmeQ41JBVjJf+eKoG1CcLNTO
ZarjnOjy4vSNW8oCHZVAGg8SD/Jokd8bLcoURcwM4yniquw9sT1P/CJgFtnTBQoqrf1t
ve3yGHu9rfCXvitOzLjN1E0ZJ00a3QgKnWMcCEZLoZtVll3UGJSXmWaGnobtK+z+wFpZ
orgUBhASDUemYUq1KNzZYzLjoW6JOXISQFOS/t1CYQmGiPyV5lod+uE/NE20h18K6Q4H
jH+Gsk9N32CImyoTP6AOS8ExBDRJYrCyeI8aU1llRuaks7kpGw/ZASwzvlMFgATuH3Aa
5cSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=W46JZKifx/nB6GgWct+upRd0S2VgG26cKbgSp+ldtZ4=;
b=gZtCcDwAQ7xflLaAOmqsQY39lwhatPk0fWXuxSZXiHnbnI4YEVY34uW0YR/I493SSK
7O3PMir6tvv0qQPv5sot/VYF8ePg5SNTWSDvy150qtu55uhVWQPpBdCGnETXa1Gq07Jm
aAugeqQMcOAM1Ur3O5z8PMjsGYF/fSdW37aFRaczVOPlxohAhnfaSznxSKeVIPOOW+Py
sYGD8sO8M/O9qeK0pCtJ4Kx+sQqRafhvJ8poPVsueGom4ci5TGHQjQ7rUi3WcotmIYp7
G2ZVi8zUaXCgsrd2AQOzZdootaKMPcGewxOQdxeIKJlH3N0ZCXw/glb6qva7jkNisFZP
XDWw==
X-Gm-Message-State: AIkVDXKu1qX8i51cRUB50kUuo8fFxEn15Y2WM6qqBgbTRxDR1/bvXGJopxML7VAUaKNuNhNcUb7Z/CiEHIXRLg==
X-Received: by 10.31.0.67 with SMTP id 64mr3373291vka.167.1485497615237; Thu,
26 Jan 2017 22:13:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.152.19 with HTTP; Thu, 26 Jan 2017 22:13:34 -0800 (PST)
Received: by 10.103.152.19 with HTTP; Thu, 26 Jan 2017 22:13:34 -0800 (PST)
In-Reply-To: <CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
References: <201701270107.01092.luke@dashjr.org>
<CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
<CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@mail.gmail.com>
<201701270414.18553.luke@dashjr.org>
<CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
From: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Fri, 27 Jan 2017 00:13:34 -0600
Message-ID: <CAAy62_LeNi1djDmArX0RWW=rD0GJU9eSqCy0o4G9eg3Y7O+0Wg@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a113daaa4abc81b05470d5d9f
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 27 Jan 2017 11:03:25 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 27 Jan 2017 06:13:37 -0000
--001a113daaa4abc81b05470d5d9f
Content-Type: text/plain; charset=UTF-8
On Jan 26, 2017 10:15 PM, "Luke Dashjr" <luke@dashjr.org> wrote:
On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote:
> Comment on #1. You're dropping the blocksize limit to 300KB and only
> reaching the limit that we have in place today 7 years later?
The limit only drops all the way to 300k if it activates before 2017 April.
Considering that this requires the consensus of a hardfork, followed by a
release in software, and then actual activation by miners using BIP9, I
think
it's extremely unlikely to activate by then.
But more importantly: such a drop would probably be good for the network in
the long-term. As explained in the Rationale section, 300k is necessary to
maintain our *current* IBD (first-time node sync) costs even with
technological improvements (which appear to be slowing lately).
Other researchers have come to the conservative conclusion that we could
handle 4MB blocks today. Imagine bitcoin had been invented in 1987 and had
a block size correspondent to the internet connections and hard drive sizes
of the day. Your proposal would have probably brought us from 1Kb(then
reduced to 300 bytes) and up to a whopping 20Kb or so today. Yet even you
think we can handle 15x that today.
You drastically underestimate the speed of technological progression, and
seem to fancy yourself the central planner of bitcoin. Isn't that one of
the things we're trying to get away from, centrally planned economics?
> We're already at capacity today, surely you're not serious with this
> proposal?
We are only at capacity because the space is available below actual costs,
and/or because efficient alternatives are not yet widely supported. A
reduction of block size will likely squeeze out spam, and perhaps some
unsustainable microtransaction use, but the volume which actually *benefits
from* the blockchain's security should continue along fine. Furthermore,
once
Lightning is widely implemented as well-tested, at least microtransactions
are
likely to gain a huge improvement in efficiency, reducing legitimate usage
of
block sizes well below 300k naturally - that is frankly when I first expect
this proposal to be seriously considered for activation (which is
independent
from the consensus to include support for it in nodes).
Legitimate usage is a transaction that pays the appropriate fee to be
included. The term legitimate transaction should be stricken from one's
vocabulary when describing a censorship resistant system such as bitcoin.
> When you promised code for a hard forking block size increase in the HK
> agreement I don't believe that a decrease first was made apparent. While
> not technically in violation of the letter of the agreement, I think this
> is a pretty obviously not in the spirit of it.
I did not mention the HK "roundtable", because this is indeed not in the
spirit of what we set out to do, and do not wish this to be interpreted as
some kind of slap in the face of the honest participants of that discussion.
Too late for that, I suspect.
This proposal is, however, the best I am currently able to honestly
recommend
that meets the hard criteria outlined at Hong Kong a year ago. (Continued
work
on the MMHF/SHF concept may eventually deliver a better solution, but it is
not yet ready.)
Luke
--001a113daaa4abc81b05470d5d9f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Jan 26, 2017 10:15 PM, "Luke Dashjr" <<a href=3D"=
mailto:luke@dashjr.org">luke@dashjr.org</a>> wrote:<br type=3D"attributi=
on"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div class=3D"quoted-text">On Friday, January =
27, 2017 3:04:50 AM Andrew Johnson wrote:<br>
> Comment on #1.=C2=A0 You're dropping the blocksize limit to 300KB =
and only<br>
> reaching the limit that we have in place today 7 years later?<br>
<br>
</div>The limit only drops all the way to 300k if it activates before 2017 =
April.<br>
Considering that this requires the consensus of a hardfork, followed by a<b=
r>
release in software, and then actual activation by miners using BIP9, I thi=
nk<br>
it's extremely unlikely to activate by then.<br>
<br>
But more importantly: such a drop would probably be good for the network in=
<br>
the long-term. As explained in the Rationale section, 300k is necessary to<=
br>
maintain our *current* IBD (first-time node sync) costs even with<br>
technological improvements (which appear to be slowing lately).<br></blockq=
uote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Other =
researchers have come to the conservative conclusion that we could handle 4=
MB blocks today.=C2=A0 Imagine bitcoin had been invented in 1987 and had a =
block size correspondent to the internet connections and hard drive sizes o=
f the day.=C2=A0 Your proposal would have probably brought us from 1Kb(then=
reduced to 300 bytes) and up to a whopping 20Kb or so today.=C2=A0 Yet eve=
n you think we can handle 15x that today.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">You drastically underestimate the speed of technological =
progression, and seem to fancy yourself the central planner of bitcoin.=C2=
=A0 Isn't that one of the things we're trying to get away from, cen=
trally planned economics?</div><div dir=3D"auto"><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"quoted-text"><br>
> We're already at capacity today, surely you're not serious wit=
h this<br>
> proposal?<br>
<br>
</div>We are only at capacity because the space is available below actual c=
osts,<br>
and/or because efficient alternatives are not yet widely supported. A<br>
reduction of block size will likely squeeze out spam, and perhaps some<br>
unsustainable microtransaction use, but the volume which actually *benefits=
<br>
from* the blockchain's security should continue along fine. Furthermore=
, once<br>
Lightning is widely implemented as well-tested, at least microtransactions =
are<br>
likely to gain a huge improvement in efficiency, reducing legitimate usage =
of<br>
block sizes well below 300k naturally - that is frankly when I first expect=
<br>
this proposal to be seriously considered for activation (which is independe=
nt<br>
from the consensus to include support for it in nodes).<br></blockquote></d=
iv></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">Legitimate usa=
ge is a transaction that pays the appropriate fee to be included.=C2=A0 The=
term legitimate transaction should be stricken from one's vocabulary w=
hen describing a censorship resistant system such as bitcoin.</div><div dir=
=3D"auto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote=
class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div class=3D"quoted-text"><br>
> When you promised code for a hard forking block size increase in the H=
K<br>
> agreement I don't believe that a decrease first was made apparent.=
=C2=A0 While<br>
> not technically in violation of the letter of the agreement, I think t=
his<br>
> is a pretty obviously not in the spirit of it.<br>
<br>
</div>I did not mention the HK "roundtable", because this is inde=
ed not in the<br>
spirit of what we set out to do, and do not wish this to be interpreted as<=
br>
some kind of slap in the face of the honest participants of that discussion=
.</blockquote></div></div></div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Too late for that, I suspect.</div><div dir=3D"auto"></div><div dir=3D"a=
uto"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote clas=
s=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<br>
This proposal is, however, the best I am currently able to honestly recomme=
nd<br>
that meets the hard criteria outlined at Hong Kong a year ago. (Continued w=
ork<br>
on the MMHF/SHF concept may eventually deliver a better solution, but it is=
<br>
not yet ready.)<br>
<font color=3D"#888888"><br>
Luke<br>
</font></blockquote></div><br></div></div></div>
--001a113daaa4abc81b05470d5d9f--
|
