summaryrefslogtreecommitdiff
path: root/07/e6da6d6235634d916641be4c13585ba47f544c
blob: 5b2d600ece64fc2222d9b820b6682ae3f1afbc13 (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
323
324
325
326
327
328
329
330
331
332
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C7F7ABC4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 23:07:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
	[209.85.220.171])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC3361B4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 23:07:42 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id y201so142212943qka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 16:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=sQCuWmLY7AE2H9AgjiyWT3fhL8T3bYfU9lT8KqjT7u4=;
	b=uHDg0ryXj3ekE03cWSVMx6CvceX5SqDS0ydhdKyAFI8YFcjXS5O6lp61khUKPMy6jz
	h/YnfIwp4qrj68benh763smxDE/vKkrP+ba079yQh9GeKMPnVtHjGDe8tWYfCzSet9/p
	0ChjT/hd/4wn8yfWTo8ACrjmxzQEC0eGp4I5/JyPj9gjGSz3jfEIV74fuFnOdy7i/ahz
	OA8ylCSpWB1WVF7OmSbm7+LT7Pd3xPVOz1yCY7K4U9he3wKXPx1Y0zDqjVdCJcFkdzIm
	8VHhhR/bUCzbOlTZUyYdR0Af73jsPkC+210PKkqnSBhxzTu2hgeLtGlkKcIqXSUIzmtl
	KazQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=sQCuWmLY7AE2H9AgjiyWT3fhL8T3bYfU9lT8KqjT7u4=;
	b=ZjGE797LwPTGQJdpG5ROmlFSGHuQv/9HBPeCphY89lI6b4l2djcyu4I0HG0cCUQ5GJ
	LsPIthnw674iju95/lE0WFtRFThio6SvAcEjjrWH6p0YcpSBiuEnP4OWX73UkrHlFKrz
	p2JJgKbBMlRdPp2rmXFw6hzT8hKW4NfV8E5UcQfWQ4DmS2vUdGfPGt2lEHh7cSCZ1nNh
	MKFdWYW2VjenTlD1hfZGv4vpTK/OU1WtXRX+4LrqiGv1X5f0NXlCW2SQ3Iu3sEb3XGQ5
	QpKyv2RO+YMI+pPD4BWxsTOWRk+SdeCldPypNR4XdVePZb/ickOk+eAIm84Tj7cJySm+
	Rz9Q==
X-Gm-Message-State: AODbwcBqoIU46c5UgU31P98OgazVu2PU6m87IdT05TinFuqe1mKtt5+u
	6EO9kEOjM6FShTX9tiVy7/PfIkQB3w==
X-Received: by 10.55.141.67 with SMTP id p64mr29315677qkd.164.1495580861891;
	Tue, 23 May 2017 16:07:41 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.48.102 with HTTP; Tue, 23 May 2017 16:07:41 -0700 (PDT)
In-Reply-To: <201705232023.40588.luke@dashjr.org>
References: <201705232023.40588.luke@dashjr.org>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 23 May 2017 19:07:41 -0400
X-Google-Sender-Auth: rONvT9kwLOYlW3LO_TYd3jqZKHM
Message-ID: <CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary="94eb2c084666018a1e0550390e09"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Wed, 24 May 2017 01:58:07 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
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, 23 May 2017 23:07:43 -0000

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

Personally, I would prefer if a 2MB lock-in that uses BIP103 for the
timing.

I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM
growth, of which bandwidth seems the most constraining.

- Erik


On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> In light of some recent discussions, I wrote up this BIP for a real 2 MB
> block
> size hardfork following Segwit BIP148 activation. This is not part of any
> agreement I am party to, nor anything of that sort. Just something to throw
> out there as a possible (and realistic) option.
>
> Note that I cannot recommend this to be adopted, since frankly 1 MB blocks
> really are still too large, and this blunt-style hardfork quite risky even
> with consensus. But if the community wishes to adopt (by unanimous
> consensus)
> a 2 MB block size hardfork, this is probably the best way to do it right
> now.
> The only possible way to improve on this IMO would be to integrate it into
> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size HF
> improvements).
>
> I have left Author blank, as I do not intend to personally champion this.
> Before it may be assigned a BIP number, someone else will need to step up
> to
> take on that role. Motivation and Rationale are blank because I do not
> personally think there is any legitimate rationale for such a hardfork at
> this
> time; if someone adopts this BIP, they should complete these sections. (I
> can
> push a git branch with the BIP text if someone wants to fork it.)
>
> <pre>
> BIP: ?
> Layer: Consensus (hard fork)
> Title: Post-segwit 2 MB block size hardfork
> Author: FIXME
> Comments-Summary: No comments yet.
> Comments-URI: ?
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-2-Clause
> </pre>
>
> ==Abstract==
>
> Legacy Bitcoin transactions are given the witness discount, and a block
> size
> limit of 2 MB is imposed.
>
> ==Copyright==
>
> This BIP is licensed under the BSD 2-clause license.
>
> ==Specification==
>
> Upon activation, a block size limit of 2000000 bytes is enforced.
> The block weight limit remains at 4000000 WU.
>
> The calculation of block weight is modified:
> all witness data, including both scriptSig (used by pre-segwit inputs) and
> segwit witness data, is measured as 1 weight-unit (WU), while all other
> data
> in the block is measured as 4 WU.
>
> The witness commitment in the generation transaction is no longer required,
> and instead the txid merkle root in the block header is replaced with a
> hash
> of:
>
> 1. The witness reserved value.
> 2. The witness merkle root hash.
> 3. The transaction ID merkle root hash.
>
> The maximum size of a transaction stripped of witness data is limited to 1
> MB.
>
> ===Deployment===
>
> This BIP is deployed by flag day, in the block where the median-past time
> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).
>
> It is assumed that when this flag day has been reached, Segwit has been
> activated via BIP141 and/or BIP148.
>
> ==Motivation==
>
> FIXME
>
> ==Rationale==
>
> FIXME
>
> ==Backwards compatibility==
>
> This is a hardfork, and as such not backward compatible.
> It should not be deployed without consent of the entire Bitcoin community.
> Activation is scheduled for 18 months from the creation date of this BIP,
> intended to give 6 months to establish consensus, and 12 months for
> deployment.
>
> ==Reference implementation==
>
> FIXME
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Personally, I would prefer if a 2MB lock-in that uses BIP1=
03 for the timing. =C2=A0=C2=A0<br><br>I think up to 20% per year can be ab=
sorbed by averages in bandwidth/CPU/RAM growth, of which bandwidth seems th=
e most constraining.<br><br>- Erik<br><br></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr=
 via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In light of some =
recent discussions, I wrote up this BIP for a real 2 MB block<br>
size hardfork following Segwit BIP148 activation. This is not part of any<b=
r>
agreement I am party to, nor anything of that sort. Just something to throw=
<br>
out there as a possible (and realistic) option.<br>
<br>
Note that I cannot recommend this to be adopted, since frankly 1 MB blocks<=
br>
really are still too large, and this blunt-style hardfork quite risky even<=
br>
with consensus. But if the community wishes to adopt (by unanimous consensu=
s)<br>
a 2 MB block size hardfork, this is probably the best way to do it right no=
w.<br>
The only possible way to improve on this IMO would be to integrate it into<=
br>
MMHF/&quot;spoonnet&quot; style hardfork (and/or add other unrelated-to-blo=
ck-size HF<br>
improvements).<br>
<br>
I have left Author blank, as I do not intend to personally champion this.<b=
r>
Before it may be assigned a BIP number, someone else will need to step up t=
o<br>
take on that role. Motivation and Rationale are blank because I do not<br>
personally think there is any legitimate rationale for such a hardfork at t=
his<br>
time; if someone adopts this BIP, they should complete these sections. (I c=
an<br>
push a git branch with the BIP text if someone wants to fork it.)<br>
<br>
&lt;pre&gt;<br>
BIP: ?<br>
Layer: Consensus (hard fork)<br>
Title: Post-segwit 2 MB block size hardfork<br>
Author: FIXME<br>
Comments-Summary: No comments yet.<br>
Comments-URI: ?<br>
Status: Draft<br>
Type: Standards Track<br>
Created: 2017-05-22<br>
License: BSD-2-Clause<br>
&lt;/pre&gt;<br>
<br>
=3D=3DAbstract=3D=3D<br>
<br>
Legacy Bitcoin transactions are given the witness discount, and a block siz=
e<br>
limit of 2 MB is imposed.<br>
<br>
=3D=3DCopyright=3D=3D<br>
<br>
This BIP is licensed under the BSD 2-clause license.<br>
<br>
=3D=3DSpecification=3D=3D<br>
<br>
Upon activation, a block size limit of 2000000 bytes is enforced.<br>
The block weight limit remains at 4000000 WU.<br>
<br>
The calculation of block weight is modified:<br>
all witness data, including both scriptSig (used by pre-segwit inputs) and<=
br>
segwit witness data, is measured as 1 weight-unit (WU), while all other dat=
a<br>
in the block is measured as 4 WU.<br>
<br>
The witness commitment in the generation transaction is no longer required,=
<br>
and instead the txid merkle root in the block header is replaced with a has=
h<br>
of:<br>
<br>
1. The witness reserved value.<br>
2. The witness merkle root hash.<br>
3. The transaction ID merkle root hash.<br>
<br>
The maximum size of a transaction stripped of witness data is limited to 1 =
MB.<br>
<br>
=3D=3D=3DDeployment=3D=3D=3D<br>
<br>
This BIP is deployed by flag day, in the block where the median-past time<b=
r>
surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).<br>
<br>
It is assumed that when this flag day has been reached, Segwit has been<br>
activated via BIP141 and/or BIP148.<br>
<br>
=3D=3DMotivation=3D=3D<br>
<br>
FIXME<br>
<br>
=3D=3DRationale=3D=3D<br>
<br>
FIXME<br>
<br>
=3D=3DBackwards compatibility=3D=3D<br>
<br>
This is a hardfork, and as such not backward compatible.<br>
It should not be deployed without consent of the entire Bitcoin community.<=
br>
Activation is scheduled for 18 months from the creation date of this BIP,<b=
r>
intended to give 6 months to establish consensus, and 12 months for<br>
deployment.<br>
<br>
=3D=3DReference implementation=3D=3D<br>
<br>
FIXME<br>
<br>
<br>
<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>
</blockquote></div><br></div>

--94eb2c084666018a1e0550390e09--