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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8200BB77
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 May 2017 21:24:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f50.google.com (mail-it0-f50.google.com
[209.85.214.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F295924C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 May 2017 21:24:41 +0000 (UTC)
Received: by mail-it0-f50.google.com with SMTP id r63so1052095itc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 30 May 2017 14:24:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=ULATwgXY+kDNfaa7oJ55gwx5KIIQqpcq0JreLlDlJuM=;
b=G+pGHExuzg78wmQOIT/PdegREdaXT3mN3eGh1HJilAtXvEVdZ1wuIMEhCOEYrdti7Z
qvpEvMJ4IomScPqSqqnWPxFz/ZVdhl5+0aUDt4Wnn7j7w1W5gUbvxy6jyrO8B9CMcbFB
UBXFcft+Q876Gxi4vb0FxV4xB9k7x+hBwvl9GgnmZrQmrlElrOyt7gYBXN01YfJ+PDfl
B1q4PrrHoiDwcxKgOQPIihW1ZnBlZwqzZhcwx8xMNOgptmmFZ2Bn75qAsEF45ZP55ItT
2GeFnZ8TfpZpbefdSE925/3PzNpxjhMCVxMDqFplA5W0U8sobA9AI4OJ9FFEbygfA9AU
728A==
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:content-transfer-encoding;
bh=ULATwgXY+kDNfaa7oJ55gwx5KIIQqpcq0JreLlDlJuM=;
b=haLH43jHru9A9uqsZy4UhpNpJ75BGLcthZ0s8v903Xov9WhiY1QybuZxLBC8ucesc0
M1a/7UsrBR6Dc7SpycGCKRku7zy3GyNlYV+joVsIL0dyOiuh4X9LiDWgKEOe88CQAx4B
H9ww6+8VX+I0rgJnvBd+yrJe0EJuX/Qa3YsWS8gOyZ6JK41vieICWeipAdi7Ey66om7P
+OCq6Crd3UxJPp4JCquOgd1OCy8r4jdoPZlTLxl6ZchTTqKPCweXgIFGIjCMLLgKdiz0
Bn+A9Hof7A3yhdisxpIiTEeeQKzDai+6Kp+zZl7vQQHbupR7pHLQQjVsMJoRcI/sSvGq
hCcg==
X-Gm-Message-State: AODbwcAntlb+pjVq+JLm6rZ9JbdfXp81RN4cD3UcDpKhvwdlvY5vpOKE
M8V/IPC84p95ptHb6ZfbvR1F+E0CjJYD
X-Received: by 10.36.78.201 with SMTP id r192mr4213666ita.45.1496179481095;
Tue, 30 May 2017 14:24:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.11.199 with HTTP; Tue, 30 May 2017 14:24:20 -0700 (PDT)
X-Originating-IP: [73.189.35.88]
In-Reply-To: <CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>
References: <201705232023.40588.luke@dashjr.org>
<CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com>
<CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Tue, 30 May 2017 14:24:20 -0700
Message-ID: <CAOG=w-uei5-c-Mpp_R6RrN29NTrSV+gpNd79FC3cB6QPG65sEw@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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: Tue, 30 May 2017 21:33:41 +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, 30 May 2017 21:24:45 -0000
The 1MB classic block size is not redundant after segwit activation.
Segwit prevents the quadratic hashing problems, but only for segwit
outputs. The 1MB classic block size prevents quadratic hashing
problems from being any worse than they are today.
Mark
On Tue, May 30, 2017 at 6:27 AM, Jorge Tim=C3=B3n via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Why not simply remove the (redundant after sw activation) 1 mb size
> limit check and increasing the weight limit without changing the
> discount or having 2 limits?
>
>
> On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Personally, I would prefer if a 2MB lock-in that uses BIP103 for the tim=
ing.
>>
>> 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 M=
B
>>> block
>>> size hardfork following Segwit BIP148 activation. This is not part of a=
ny
>>> 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 blo=
cks
>>> really are still too large, and this blunt-style hardfork quite risky e=
ven
>>> 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 righ=
t
>>> now.
>>> The only possible way to improve on this IMO would be to integrate it i=
nto
>>> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-siz=
e
>>> HF
>>> improvements).
>>>
>>> I have left Author blank, as I do not intend to personally champion thi=
s.
>>> 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>
>>>
>>> =3D=3DAbstract=3D=3D
>>>
>>> Legacy Bitcoin transactions are given the witness discount, and a block
>>> size
>>> limit of 2 MB is imposed.
>>>
>>> =3D=3DCopyright=3D=3D
>>>
>>> This BIP is licensed under the BSD 2-clause license.
>>>
>>> =3D=3DSpecification=3D=3D
>>>
>>> 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 t=
o 1
>>> MB.
>>>
>>> =3D=3D=3DDeployment=3D=3D=3D
>>>
>>> This BIP is deployed by flag day, in the block where the median-past ti=
me
>>> 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.
>>>
>>> =3D=3DMotivation=3D=3D
>>>
>>> FIXME
>>>
>>> =3D=3DRationale=3D=3D
>>>
>>> FIXME
>>>
>>> =3D=3DBackwards compatibility=3D=3D
>>>
>>> This is a hardfork, and as such not backward compatible.
>>> It should not be deployed without consent of the entire Bitcoin communi=
ty.
>>> Activation is scheduled for 18 months from the creation date of this BI=
P,
>>> intended to give 6 months to establish consensus, and 12 months for
>>> deployment.
>>>
>>> =3D=3DReference implementation=3D=3D
>>>
>>> FIXME
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
