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
|
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 2E6B992B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2017 03:04:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com
[209.85.217.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6BFDB1D7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Jan 2017 03:04:51 +0000 (UTC)
Received: by mail-ua0-f180.google.com with SMTP id i68so196085772uad.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 26 Jan 2017 19:04:51 -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;
bh=7heD2OcMnjvhcMAVr6LQQ7FXpA/YH73uhjWps3PxVKA=;
b=la3Bpg5T8HOwnqL2Xtlo6PoWPYcA5jlWousALkrWv5048RLZf5nwz+LRrpKaUZcWby
W8gs1p20+z5ZbOORxq/HZFWxAtC1YZ43MQQPbkYhGYQIDqkuPGyJrbW2JJLvrhHFPLyw
O+8EyvQhJwHhjeKB2g53PqebBKrc5zii5O5SpyoGP+XEWCDezYoZn/Ory5kkyNq5CgzF
gUpFZQMT9EmAJY0ZdaGQzYvdsUhAJN9LeOFKpLSx1blUoAFql6RKuQ/mqj1vxyBFFznA
lQNRHkzjkgczilHPzUiejZFPrAqGRgaeBIv5uCRWpE38nHjGnU95EG3V0epgTd2ly8Es
pthg==
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;
bh=7heD2OcMnjvhcMAVr6LQQ7FXpA/YH73uhjWps3PxVKA=;
b=RNBT909oGSYmc6mSFqlU7ZQ9EbKEMBGTk6VqFUE9oN8VoSUYSi7xL2lK8FIUrqfCUx
cwfwDsKBuawcJSCHcG8FdHR2M1kwJO4oDT4IQ/2pF7v/swhHtUxB2FvvHaaPIz2aMzOA
Yq+PZhTQx18YLGJj2/UfQlu9NetlWdVpn5lnsz65H4VezMYoFOJWTIAWO4VhDJzg7LX7
GhIGy4yFKCN9y7WR+upXOa7hRPCw4ajEIUfg/3N9y43fLC8KrLoug3Zl5sgzTm9KTbTJ
U+MqUqTAlNuPiXCvhTt9pzBk9eWKlIcktCBbPBwuAzgLorcneEKv8PaGxds3ERZI+FPO
irdA==
X-Gm-Message-State: AIkVDXKpuj/j1Mg5/uHlDp0pf87ztTOh3ogSAS2yqiLyu46i1kUGHGOEwdvpM2Rza3LhPpftKg5TM0MebXpNoQ==
X-Received: by 10.159.37.71 with SMTP id 65mr2757797uaz.134.1485486290579;
Thu, 26 Jan 2017 19:04:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.152.19 with HTTP; Thu, 26 Jan 2017 19:04:50 -0800 (PST)
Received: by 10.103.152.19 with HTTP; Thu, 26 Jan 2017 19:04:50 -0800 (PST)
In-Reply-To: <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
References: <201701270107.01092.luke@dashjr.org>
<CAAy62_L-mLhokVy4_WeLBVnxM0Y76dtFBaaDrRvQozxw=J1Ctw@mail.gmail.com>
<CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
From: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Thu, 26 Jan 2017 21:04:50 -0600
Message-ID: <CAAy62_JuWMQ=HMmcw8GsQSDM8S+4LJeG1GHw1OdT+mQC3H-DOA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c12308aab373205470abaae
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 04:35:41 +0000
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 03:04:52 -0000
--94eb2c12308aab373205470abaae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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? We're
already at capacity today, surely you're not serious with this proposal?
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.
On Jan 26, 2017 7:07 PM, "Luke Dashjr via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
I've put together three hardfork-related BIPs. This is parallel to the
ongoing
research into the MMHF/SHF WIP BIP, which might still be best long-term.
1) The first is a block size limit protocol change. It also addresses three
criticisms of segwit: 1) segwit increases the block size limit which is
already considered by many to be too large; 2) segwit treats pre-segwit
transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount only=
to segwit
transactions; and 3) that spam blocks can be larger than blocks mining
legitimate transactions. This proposal may (depending on activation date)
initially reduce the block size limit to a more sustainable size in the
short-
term, and gradually increase it up over the long-term to 31 MB; it will als=
o
extend the witness discount to non-segwit transactions. Should the initial
block size limit reduction prove to be too controversial, miners can simply
wait to activate it until closer to the point where it becomes acceptable
and/or increases the limit. However, since the BIP includes a hardfork, the
eventual block size increase needs community consensus before it can be
deployed. Proponents of block size increases should note that this BIP does
not interfere with another more aggressive block size increase hardfork in
the
meantime. I believe I can immediately recommend this for adoption; however,
peer and community review are welcome to suggest changes.
Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawik=
i
Code: https://github.com/bitcoin/bitcoin/compare/master...luke-
jr:bip-blksize
(consensus code changes only)
2) The second is a *preparatory* change, that should allow trivially
transforming certain classes of hardforks into softforks in the future. It
essentially says that full nodes should relax their rule enforcement, after
sufficient time that would virtually guarantee they have ceased to be
enforcing the full set of rules anyway. This allows these relaxed rules to
be
modified or removed in a softfork, provided the proposal to do so is
accepted
and implemented with enough advance notice. Attempting to implement this ha=
s
proven more complicated than I originally expected, and it may make more
sense
for full nodes to simply stop functioning (with a user override) after the
cut-off date). In light of this, I do not yet recommend its adoption, but a=
m
posting it for review and comments only.
Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki
3) Third is an anti-replay softfork which can be used to prevent replay
attacks whether induced by a hardfork-related chain split, or even in
ordinary
operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for
the
Bitcoin scripting system that allows construction of transactions which are
valid only on specific blockchains.
Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-
noreplay.mediawiki
Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--94eb2c12308aab373205470abaae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>Comment on #1.=C2=A0 You're dropping the blocksi=
ze limit to 300KB and only reaching the limit that we have in place today 7=
years later?=C2=A0 We're already at capacity today, surely you're =
not serious with this proposal?=C2=A0 When you promised code for a hard for=
king block size increase in the HK agreement I don't believe that a dec=
rease first was made apparent.=C2=A0 While not technically in violation of =
the letter of the agreement, I think this is a pretty obviously not in the =
spirit of it.</div><div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto=
"><br><div class=3D"gmail_quote">On Jan 26, 2017 7:07 PM, "Luke Dashjr=
via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"at=
tribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">I've put together three hardfork-re=
lated BIPs. This is parallel to the ongoing<br>
research into the MMHF/SHF WIP BIP, which might still be best long-term.<br=
>
<br>
1) The first is a block size limit protocol change. It also addresses three=
<br>
criticisms of segwit: 1) segwit increases the block size limit which is<br>
already considered by many to be too large; 2) segwit treats pre-segwit<br>
transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount only=
to segwit<br>
transactions; and 3) that spam blocks can be larger than blocks mining<br>
legitimate transactions. This proposal may (depending on activation date)<b=
r>
initially reduce the block size limit to a more sustainable size in the sho=
rt-<br>
term, and gradually increase it up over the long-term to 31 MB; it will als=
o<br>
extend the witness discount to non-segwit transactions. Should the initial<=
br>
block size limit reduction prove to be too controversial, miners can simply=
<br>
wait to activate it until closer to the point where it becomes acceptable<b=
r>
and/or increases the limit. However, since the BIP includes a hardfork, the=
<br>
eventual block size increase needs community consensus before it can be<br>
deployed. Proponents of block size increases should note that this BIP does=
<br>
not interfere with another more aggressive block size increase hardfork in =
the<br>
meantime. I believe I can immediately recommend this for adoption; however,=
<br>
peer and community review are welcome to suggest changes.<br>
Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksi=
ze.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-=
jr/<wbr>bips/blob/bip-blksize/bip-<wbr>blksize.mediawiki</a><br>
Code: <a href=3D"https://github.com/bitcoin/bitcoin/compare/master...luke-j=
r:bip-blksize" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitc=
oin/<wbr>bitcoin/compare/master...luke-<wbr>jr:bip-blksize</a><br>
(consensus code changes only)<br>
<br>
2) The second is a *preparatory* change, that should allow trivially<br>
transforming certain classes of hardforks into softforks in the future. It<=
br>
essentially says that full nodes should relax their rule enforcement, after=
<br>
sufficient time that would virtually guarantee they have ceased to be<br>
enforcing the full set of rules anyway. This allows these relaxed rules to =
be<br>
modified or removed in a softfork, provided the proposal to do so is accept=
ed<br>
and implemented with enough advance notice. Attempting to implement this ha=
s<br>
proven more complicated than I originally expected, and it may make more se=
nse<br>
for full nodes to simply stop functioning (with a user override) after the<=
br>
cut-off date). In light of this, I do not yet recommend its adoption, but a=
m<br>
posting it for review and comments only.<br>
Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep=
.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-jr=
/<wbr>bips/blob/bip-hfprep/bip-<wbr>hfprep.mediawiki</a><br>
<br>
3) Third is an anti-replay softfork which can be used to prevent replay<br>
attacks whether induced by a hardfork-related chain split, or even in ordin=
ary<br>
operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for t=
he<br>
Bitcoin scripting system that allows construction of transactions which are=
<br>
valid only on specific blockchains.<br>
Text: <a href=3D"https://github.com/luke-jr/bips/blob/bip-noreplay/bip-nore=
play.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luk=
e-jr/<wbr>bips/blob/bip-noreplay/bip-<wbr>noreplay.mediawiki</a><br>
<br>
Luke<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></div></div>
--94eb2c12308aab373205470abaae--
|