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
|
Return-Path: <nathan.cook@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5C009516
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Jun 2017 16:27:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com
[209.85.217.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B78A712A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Jun 2017 16:27:35 +0000 (UTC)
Received: by mail-ua0-f181.google.com with SMTP id 68so41949330uas.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Jun 2017 09:27:35 -0700 (PDT)
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=06TRNlAhE5+XRmi0qZEZh6OUgV/0lvk8K7HkXeFvi2A=;
b=F8FJaTSZIf0Re4dWIzkxuxjhKNKcQf97ePuHuRXewCpMysMx4kw5lcnh0Opd3rWE4Z
K2Mtaaf8BEaMAzYgQFM3XLty0l3NMB3EGOvzCG2Ha0vQDo/OPzoGhkDFhtFfhn2EZ/K0
OlmYi/7v0C2K3N1+4xXCJV40vwZK0l+4CxkggugLV2Jjw4eniTwCHtsRtSaeAZV/BEE+
tSoKPytBuuYsn88r/eWpCKkuNleIZSqvjFjPapoIbjKJ7fANLDBQXTppj+a5EPUqolgU
dcdrNGZ3t82YOs9W9dq3S0pvbVjRKD7dOMHO5vGRXiWpyL3MXzOiwZ89kM8n3x+fr3wy
6YLA==
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=06TRNlAhE5+XRmi0qZEZh6OUgV/0lvk8K7HkXeFvi2A=;
b=hxldNOjzcDsgVHyNfs4g9IthoHWJFCq6UEzdBFgYiWUBQi7mr43BFEDvxUH/DBJneW
ocCzi4/GGMiGLfgD9sj17wITIgnZgH1Jm6opU9+w+ojjXZ47Gn/PbcN6hTs8M886uMGe
m7jh37zMPDoCN+nmp+cJCe4BjOxEUrkdQ2197NfK3vLQB4HFC967QR50MAIwXrkb+QQV
Pw1qMQkrkzC6I562q0cM7GdTiHpqmt16FJDTQr0qScqE10YOiellHTLBDKGeS4MYwSyk
taKzrpRaI2lzH8+VIIG5PwqAAfnMiX95koQvlzZaIBYM5srsKq2nLp6pFd3Sy1Slxtgk
FzlA==
X-Gm-Message-State: AODbwcCgGYJ8V/1pwmHBwm4YYB6xg92jN62Jdn/NdyWwPXL1HLg2DbkZ
f062Eolfy2cOjEkpYfgCC5NyDWIOiA==
X-Received: by 10.176.95.217 with SMTP id g25mr24032343uaj.71.1497284854781;
Mon, 12 Jun 2017 09:27:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.41.134 with HTTP; Mon, 12 Jun 2017 09:27:14 -0700 (PDT)
In-Reply-To: <CAD1TkXtut2LZdp5Qo9ep2FfMGFFYqdxtobLJgoC7UutyNujKKg@mail.gmail.com>
References: <201705232023.40588.luke@dashjr.org>
<CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com>
<CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>
<CAOG=w-uei5-c-Mpp_R6RrN29NTrSV+gpNd79FC3cB6QPG65sEw@mail.gmail.com>
<CAH+Axy5yYQywpy0s9pBZt_fNoLPpWfra-cU9HrUwH71GDOchsQ@mail.gmail.com>
<004E1123-8346-48B6-9BCB-94BAE00EC34B@me.com>
<CAAUaCyjbObcb1mJVmeEDmgzNddQCY3QhrHV3fgNbin-ZyqgfeA@mail.gmail.com>
<CAD1TkXtut2LZdp5Qo9ep2FfMGFFYqdxtobLJgoC7UutyNujKKg@mail.gmail.com>
From: Nathan Cook <nathan.cook@gmail.com>
Date: Mon, 12 Jun 2017 19:27:14 +0300
Message-ID: <CAGNXQMRuR8BHFXSjxTWVsFaSs5cXfmSzVvbmds5Nqch4UnBMVQ@mail.gmail.com>
To: Jared Lee Richardson <jaredr26@gmail.com>
Content-Type: multipart/alternative; boundary="089e08204960e5a8790551c5cbd5"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
HTML_OBFUSCATE_05_10,
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: Mon, 12 Jun 2017 18:11:51 +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: Mon, 12 Jun 2017 16:27:38 -0000
--089e08204960e5a8790551c5cbd5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
The problem with >100kb transactions isn't that there are a lot of
already-signed transactions out there, or even that there are good use
cases for them, but that such transactions and use cases could exist, and
there is no way of disallowing them without possibly costing someone a lot
of money. Slowly reducing the limit doesn't really solve this problem.
I propose to make them hard enough to confirm that no-one will use them
without a very good reason. Just require that any block containing an
outsized transaction be mined at a greater difficulty =E2=80=93 quadratical=
ly
greater. Such a block is more expensive *for the block's miner*, not just
for the other miners, or for other nodes. Anyone who really, really needs
to use a 400kb transaction can pay a miner to mine it.
Quadratic hashing isn't risky when it is inherently limited by a
corresponding reduction in the rate at which the "bad" blocks can be
generated. That said, there's nothing I can see which is actually good
about large, expensive to validate transactions, and so >1MB transactions
should remain invalid, as they are today.
Nathan Cook
On 2 June 2017 at 22:40, Jared Lee Richardson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
> quadratic hashing risks, and maybe James' 10KB is too ambitious; but even
> if so, a simple 1MB tx size limit would clearly do the trick. The broade=
r
> point is that quadratic hashing is not a compelling reason to keep
> blockmaxsize post-HF: does someone have a better one?
>
> I think this is exactly the right direction to head. There are
> arguments to be made for various maximum sizes... Maybe the limit
> could be set to 1mb initially, and at a distant future block
> height(years?) automatically drop to 500kb or 100kb? That would give
> anyone with existing systems or pre-signed transactions several years
> to adjust to the change. Notification could (?possibly?) be done with
> a non-default parameter that must be changed to continue to use 100kb
> - <1mb transactions, so no one running modern software could claim
> they were not informed when that future date hits.
>
> I don't see any real advantages to continuing to support transactions
> larger than 100kb excepting the need to update legacy use cases /
> already signed transactions.
>
> On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
> > quadratic hashing risks, and maybe James' 10KB is too ambitious; but
> even if
> > so, a simple 1MB tx size limit would clearly do the trick. The broader
> > point is that quadratic hashing is not a compelling reason to keep
> > blockmaxsize post-HF: does someone have a better one?
> >
> >
> >
> > On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> That would invalidate any pre-signed transactions that are currently o=
ut
> >> there. You can't just change the rules out from under people.
> >>
> >>
> >> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>
> >>
> >>>
> >>> The 1MB classic block size prevents quadratic hashing
> >>> problems from being any worse than they are today.
> >>>
> >>
> >> Add a transaction-size limit of, say, 10kb and the quadratic hashing
> >> problem is a non-issue. Donezo.
> >>
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e08204960e5a8790551c5cbd5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The problem with >100kb transactions isn't that the=
re are a lot of already-signed transactions out there, or even that there a=
re good use cases for them, but that such transactions and use cases could =
exist, and there is no way of disallowing them without possibly costing som=
eone a lot of money. Slowly reducing the limit doesn't really solve thi=
s problem.<div><br></div><div>I propose to make them hard enough to confirm=
that no-one will use them without a very good reason. Just require that an=
y block containing an outsized transaction be mined at a greater difficulty=
=E2=80=93 quadratically greater. Such a block is more expensive *for the b=
lock's miner*, not just for the other miners, or for other nodes. Anyon=
e who really, really needs to use a 400kb transaction can pay a miner to mi=
ne it.</div><div><br></div><div>Quadratic hashing isn't risky when it i=
s inherently limited by a corresponding reduction in the rate at which the =
"bad" blocks can be generated. That said, there's nothing I c=
an see which is actually good about large, expensive to validate transactio=
ns, and so >1MB transactions should remain invalid, as they are today.<d=
iv><div><div><br></div></div></div><div class=3D"gmail_extra"><br clear=3D"=
all"><div><div class=3D"m_-3003912858490148780gmail_signature" data-smartma=
il=3D"gmail_signature">Nathan Cook</div></div>
<br><div class=3D"gmail_quote">On 2 June 2017 at 22:40, Jared Lee Richardso=
n via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundat=
ion.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> =
Maybe there's some hole in Jorge's logic and scrapping blockmaxsize=
has quadratic hashing risks, and maybe James' 10KB is too ambitious; b=
ut even if so, a simple 1MB tx size limit would clearly do the trick.=C2=A0=
The broader point is that quadratic hashing is not a compelling reason to =
keep blockmaxsize post-HF: does someone have a better one?<br>
<br>
</span>I think this is exactly the right direction to head.=C2=A0 There are=
<br>
arguments to be made for various maximum sizes... Maybe the limit<br>
could be set to 1mb initially, and at a distant future block<br>
height(years?) automatically drop to 500kb or 100kb?=C2=A0 That would give<=
br>
anyone with existing systems or pre-signed transactions several years<br>
to adjust to the change.=C2=A0 Notification could (?possibly?) be done with=
<br>
a non-default parameter that must be changed to continue to use 100kb<br>
- <1mb transactions, so no one running modern software could claim<br>
they were not informed when that future date hits.<br>
<br>
I don't see any real advantages to continuing to support transactions<b=
r>
larger than 100kb excepting the need to update legacy use cases /<br>
already signed transactions.<br>
<div class=3D"m_-3003912858490148780HOEnZb"><div class=3D"m_-30039128584901=
48780h5"><br>
On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br>
> Maybe there's some hole in Jorge's logic and scrapping blockma=
xsize has<br>
> quadratic hashing risks, and maybe James' 10KB is too ambitious; b=
ut even if<br>
> so, a simple 1MB tx size limit would clearly do the trick.=C2=A0 The b=
roader<br>
> point is that quadratic hashing is not a compelling reason to keep<br>
> blockmaxsize post-HF: does someone have a better one?<br>
><br>
><br>
><br>
> On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"=
;<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br>
>><br>
>> That would invalidate any pre-signed transactions that are current=
ly out<br>
>> there. You can't just change the rules out from under people.<=
br>
>><br>
>><br>
>> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>> wrote:<br>
>><br>
>><br>
>>><br>
>>>=C2=A0 The 1MB classic block size prevents quadratic hashing<br=
>
>>> problems from being any worse than they are today.<br>
>>><br>
>><br>
>> Add a transaction-size limit of, say, 10kb and the quadratic hashi=
ng<br>
>> problem is a non-issue. Donezo.<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
>> <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-d<wbr>ev</a><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> bitcoin-dev mailing list<br>
>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
>> <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-d<wbr>ev</a><br>
>><br>
><br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div></div></div>
--089e08204960e5a8790551c5cbd5--
|
