summaryrefslogtreecommitdiff
path: root/99/96aad42b1dcf7e670d2410092771469129f6ca
blob: d7164ad886c8704682e088c8912c8913d6eee111 (plain)
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
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F163089E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Mar 2017 17:33:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu
	[18.9.25.14])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6BAE20C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Mar 2017 17:33:57 +0000 (UTC)
X-AuditID: 1209190e-42fff70000003f09-eb-58da9e832d63
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])
	(using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by  (Symantec Messaging Gateway) with SMTP id CD.4A.16137.38E9AD85;
	Tue, 28 Mar 2017 13:33:56 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
	by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v2SHXtNN006736
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Mar 2017 13:33:55 -0400
Received: from mail-pg0-f47.google.com (mail-pg0-f47.google.com [74.125.83.47])
	(authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2SHXqFo024968
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Mar 2017 13:33:53 -0400
Received: by mail-pg0-f47.google.com with SMTP id 21so78985330pgg.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Mar 2017 10:33:53 -0700 (PDT)
X-Gm-Message-State: AFeK/H19sGmIUM7Oc5canR9OxN+x2ndCLdGqiomhU6EZK6Cw+LY7xj5DP7+wLs0LD8c5shD2q0UnE6LeuHrMvw==
X-Received: by 10.84.229.79 with SMTP id d15mr21929863pln.49.1490722432020;
	Tue, 28 Mar 2017 10:33:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.162.101 with HTTP; Tue, 28 Mar 2017 10:33:31 -0700 (PDT)
In-Reply-To: <CAFzgq-xnXw6efaEurLcgMQQwwr7YitrJ3vZ8i+Ha0MbnVzUKhg@mail.gmail.com>
References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com>
	<CAMBsKS8oSKS5g8UEyCu18bjzGJWpA+sJEaxBUV9FXAmXhX1ApA@mail.gmail.com>
	<CAFzgq-xnXw6efaEurLcgMQQwwr7YitrJ3vZ8i+Ha0MbnVzUKhg@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 28 Mar 2017 13:33:31 -0400
X-Gmail-Original-Message-ID: <CAD5xwhgU9orUAsY00PbGPH7-SuoGYF3bCigBwm1BOoDtPn26cQ@mail.gmail.com>
Message-ID: <CAD5xwhgU9orUAsY00PbGPH7-SuoGYF3bCigBwm1BOoDtPn26cQ@mail.gmail.com>
To: Wang Chun <1240902@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c19ecb404f9c8054bcddd0a
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUixCmqrNsy71aEwaa/0hZNr20dGD1+/5jM
	GMAYxWWTkpqTWZZapG+XwJXRMSW44HlYxcGNXUwNjL0eXYycHBICJhJ3e5czdzFycQgJtDFJ
	zDy/mB0kISRwl1Hi+0FriMQHJokdJ98xQyTmM0rc65eH6M6RuPW0nw3CLpZYdm0GE4jNKyAo
	cXLmExaIeh+J7cvvgdmcAoESf2YfZIIYeodRYvKqy0DNHBxsAnISH36ZgtSwCKhK3H31hxli
	ZqLE1leLGSFmBkjceboHbL6wgJvEy1MgcQ4OEYF8iS+fpUHCzAKaErcarrND2F4S64/fZ5vA
	KDwLyUWzkKRmAXUzC6hLrJ8nBBFWk7i97So7hK0tsWzha+YFjKyrGGVTcqt0cxMzc4pTk3WL
	kxPz8lKLdI31cjNL9FJTSjcxgqNAkm8H46QG70OMAhyMSjy8O/JuRQixJpYVV+YeYpTkYFIS
	5f0QBBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwvtrDlCONyWxsiq1KB8mJc3BoiTOK67RGCEk
	kJ5YkpqdmlqQWgSTleHgUJLgLZ8L1ChYlJqeWpGWmVOCkGbi4AQZzgM03AKkhre4IDG3ODMd
	In+K0Zija8bON0wcH/oPv2ESYsnLz0uVEucNBLlDAKQ0ozQPbhookXnVBuu/YhQHek6Ytxdk
	IA8wCcLNewW0iglolbgN2KqSRISUVAOjhmbX3+Rjl3h7ei6dcvgas+mnRsRqsQV1NWn6Vzn6
	wrI2NDg/dDr5ulo8pV3QTdRKtsXYbeM65/OGJSY1jBv9pjuse7pi8/c4RhOjUv6upuyozxqb
	rBOTHDw3Kp98UM0pcebJrU+3t/Z+Z1qU7La9fNvElbrupq6zju871H1J3Vfks5RhjrsSS3FG
	oqEWc1FxIgCB1VbkPwMAAA==
X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting
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: Tue, 28 Mar 2017 17:33:59 -0000

--94eb2c19ecb404f9c8054bcddd0a
Content-Type: text/plain; charset=UTF-8

I think it's probably safer to have a fork-to-minumum (e.g. minimal
coinbase+header) after a certain date than to fork up at a certain date. At
least in that case, the default isn't breaking consensus, but you still get
the same pressure to fork to a permanent solution.

I don't endorse the above proposal, but remarked for the sake of guiding
the argument you are making.


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Tue, Mar 28, 2017 at 1:31 PM, Wang Chun via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The basic idea is, let's stop the debate for whether we should upgrade
> to 2MB, 8MB or 32MiB. 32MiB is well above any proposals' upper limit,
> so any final decision would be a soft fork to this already deployed
> release. If by 2020, we still agree 1MB is enough, it can be changed
> back to 1MB limit and it would also a soft fork on top of that.
>
> On Wed, Mar 29, 2017 at 1:23 AM, Alphonse Pace <alp.bitcoin@gmail.com>
> wrote:
> > What meeting are you referring to?  Who were the participants?
> >
> > Removing the limit but relying on the p2p protocol is not really a true
> > 32MiB limit, but a limit of whatever transport methods provide.  This can
> > lead to differing consensus if alternative layers for relaying are used.
> > What you seem to be asking for is an unbound block size (or at least
> > determined by whatever miners produce).  This has the possibility (and
> even
> > likelihood) of removing many participants from the network, including
> many
> > small miners.
> >
> > 32MB in less than 3 years also appears to be far beyond limits of safety
> > which are known to exist far sooner, and we cannot expect hardware and
> > networking layers to improve by those amounts in that time.
> >
> > It also seems like it would be much better to wait until SegWit
> activates in
> > order to truly measure the effects on the network from this increased
> > capacity before committing to any additional increases.
> >
> > -Alphonse
> >
> >
> >
> > On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> I've proposed this hard fork approach last year in Hong Kong Consensus
> >> but immediately rejected by coredevs at that meeting, after more than
> >> one year it seems that lots of people haven't heard of it. So I would
> >> post this here again for comment.
> >>
> >> The basic idea is, as many of us agree, hard fork is risky and should
> >> be well prepared. We need a long time to deploy it.
> >>
> >> Despite spam tx on the network, the block capacity is approaching its
> >> limit, and we must think ahead. Shall we code a patch right now, to
> >> remove the block size limit of 1MB, but not activate it until far in
> >> the future. I would propose to remove the 1MB limit at the next block
> >> halving in spring 2020, only limit the block size to 32MiB which is
> >> the maximum size the current p2p protocol allows. This patch must be
> >> in the immediate next release of Bitcoin Core.
> >>
> >> With this patch in core's next release, Bitcoin works just as before,
> >> no fork will ever occur, until spring 2020. But everyone knows there
> >> will be a fork scheduled. Third party services, libraries, wallets and
> >> exchanges will have enough time to prepare for it over the next three
> >> years.
> >>
> >> We don't yet have an agreement on how to increase the block size
> >> limit. There have been many proposals over the past years, like
> >> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> >> on. These hard fork proposals, with this patch already in Core's
> >> release, they all become soft fork. We'll have enough time to discuss
> >> all these proposals and decide which one to go. Take an example, if we
> >> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> >> from 32MiB to 2MB will be a soft fork.
> >>
> >> Anyway, we must code something right now, before it becomes too late.
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--94eb2c19ecb404f9c8054bcddd0a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I think it&#39;s proba=
bly safer to have a fork-to-minumum (e.g. minimal=20
coinbase+header) after a certain date than to fork up at a certain date.
 At least in that case, the default isn&#39;t breaking consensus, but you=
=20
still get the same pressure to fork to a permanent solution.<br><br>I don&#=
39;t endorse the above proposal, but remarked for the sake of guiding the a=
rgument you are making.<br></div></div><div class=3D"gmail_extra"><br clear=
=3D"all"><div><br clear=3D"all"><div><div class=3D"gmail_signature" data-sm=
artmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitt=
er.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://tw=
itter.com/JeremyRubin" target=3D"_blank"></a></div></div></div>
</div>
<br><div class=3D"gmail_quote">On Tue, Mar 28, 2017 at 1:31 PM, Wang Chun v=
ia bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The basic idea is, =
let&#39;s stop the debate for whether we should upgrade<br>
to 2MB, 8MB or 32MiB. 32MiB is well above any proposals&#39; upper limit,<b=
r>
so any final decision would be a soft fork to this already deployed<br>
release. If by 2020, we still agree 1MB is enough, it can be changed<br>
back to 1MB limit and it would also a soft fork on top of that.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Wed, Mar 29, 2017 at 1:23 AM, Alphonse Pace &lt;<a href=3D"mailto:alp.bi=
tcoin@gmail.com">alp.bitcoin@gmail.com</a>&gt; wrote:<br>
&gt; What meeting are you referring to?=C2=A0 Who were the participants?<br=
>
&gt;<br>
&gt; Removing the limit but relying on the p2p protocol is not really a tru=
e<br>
&gt; 32MiB limit, but a limit of whatever transport methods provide.=C2=A0 =
This can<br>
&gt; lead to differing consensus if alternative layers for relaying are use=
d.<br>
&gt; What you seem to be asking for is an unbound block size (or at least<b=
r>
&gt; determined by whatever miners produce).=C2=A0 This has the possibility=
 (and even<br>
&gt; likelihood) of removing many participants from the network, including =
many<br>
&gt; small miners.<br>
&gt;<br>
&gt; 32MB in less than 3 years also appears to be far beyond limits of safe=
ty<br>
&gt; which are known to exist far sooner, and we cannot expect hardware and=
<br>
&gt; networking layers to improve by those amounts in that time.<br>
&gt;<br>
&gt; It also seems like it would be much better to wait until SegWit activa=
tes in<br>
&gt; order to truly measure the effects on the network from this increased<=
br>
&gt; capacity before committing to any additional increases.<br>
&gt;<br>
&gt; -Alphonse<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I&#39;ve proposed this hard fork approach last year in Hong Kong C=
onsensus<br>
&gt;&gt; but immediately rejected by coredevs at that meeting, after more t=
han<br>
&gt;&gt; one year it seems that lots of people haven&#39;t heard of it. So =
I would<br>
&gt;&gt; post this here again for comment.<br>
&gt;&gt;<br>
&gt;&gt; The basic idea is, as many of us agree, hard fork is risky and sho=
uld<br>
&gt;&gt; be well prepared. We need a long time to deploy it.<br>
&gt;&gt;<br>
&gt;&gt; Despite spam tx on the network, the block capacity is approaching =
its<br>
&gt;&gt; limit, and we must think ahead. Shall we code a patch right now, t=
o<br>
&gt;&gt; remove the block size limit of 1MB, but not activate it until far =
in<br>
&gt;&gt; the future. I would propose to remove the 1MB limit at the next bl=
ock<br>
&gt;&gt; halving in spring 2020, only limit the block size to 32MiB which i=
s<br>
&gt;&gt; the maximum size the current p2p protocol allows. This patch must =
be<br>
&gt;&gt; in the immediate next release of Bitcoin Core.<br>
&gt;&gt;<br>
&gt;&gt; With this patch in core&#39;s next release, Bitcoin works just as =
before,<br>
&gt;&gt; no fork will ever occur, until spring 2020. But everyone knows the=
re<br>
&gt;&gt; will be a fork scheduled. Third party services, libraries, wallets=
 and<br>
&gt;&gt; exchanges will have enough time to prepare for it over the next th=
ree<br>
&gt;&gt; years.<br>
&gt;&gt;<br>
&gt;&gt; We don&#39;t yet have an agreement on how to increase the block si=
ze<br>
&gt;&gt; limit. There have been many proposals over the past years, like<br=
>
&gt;&gt; BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and =
so<br>
&gt;&gt; on. These hard fork proposals, with this patch already in Core&#39=
;s<br>
&gt;&gt; release, they all become soft fork. We&#39;ll have enough time to =
discuss<br>
&gt;&gt; all these proposals and decide which one to go. Take an example, i=
f we<br>
&gt;&gt; choose to fork to only 2MB, since 32MiB already scheduled, reduce =
it<br>
&gt;&gt; from 32MiB to 2MB will be a soft fork.<br>
&gt;&gt;<br>
&gt;&gt; Anyway, we must code something right now, before it becomes too la=
te.<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--94eb2c19ecb404f9c8054bcddd0a--