summaryrefslogtreecommitdiff
path: root/95/28b35f732acfcf288c5707e6a9abc73702f1f1
blob: 44ba7b90fc1162e22470e4d76986190ec28d47e2 (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
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
Return-Path: <yifu@coinapex.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 661B3E6D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  9 Feb 2016 13:59:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f199.google.com (mail-ig0-f199.google.com
	[209.85.213.199])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 885F3E1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  9 Feb 2016 13:59:41 +0000 (UTC)
Received: by mail-ig0-f199.google.com with SMTP id rs1so249799067igb.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 09 Feb 2016 05:59:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coinapex.com; s=google;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=CLVhH07/ni33JU2VdP3x8FcFqEvKcLDbw0hguU27dYc=;
	b=aZgMjpxhScNZOOn0P4ZeKwIwrN0hrXIkXSI5iPfvEs0Ufyu/jRbSQ8UGgz9ehRUSln
	CTVocZ8sFlX3tOmSMAw8BTX3L9eIs83oTs7FVbqDs5mHpK5pSNU1wyLLRgX//X8L+2K0
	gH+pu4JGe0llhEeLpk9IU5ntBy0vz8GyBBQqM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=CLVhH07/ni33JU2VdP3x8FcFqEvKcLDbw0hguU27dYc=;
	b=E9HeLc7E2fkmBqeyrr1XrVjtl5lLndVY+Wbp35gE4+j+IWq3mzyZlyqnSFmh7qSS+A
	QCeMHcEY5yRVzYGV56MeLFUQuIuNJuFopr9vNct0acYVXbkMDo722HvxvZ8TnbDRsR/M
	u9HbvWQBNrtSOJ4n7o3iC9OVD78aD3BgZxrCIIeZI6hJurREt9HZCtrZmifAui7PkYlY
	cqwKBJA2uunjfCr4MG1Fob2+XqZIyE7+5QsEcH9zNaI+MZTVFzP0Z1sf7btS9D913eeC
	TnFJ/xEJ5j/9wywSt0yI7MeNTYM85j6t4y37WxLW+TPAVPWYwoSd4kQpPtNOkpUE5aYr
	+kbg==
X-Gm-Message-State: AG10YOQ6lnbc6in9nTid5B9GDTyB3LjJXyjIBoAdLsafT5R2ILeLnW8pos9/hZc4R9/9P7aIo7UVhi+99DCO1w==
X-Received: by 10.60.117.137 with SMTP id ke9mr30792656oeb.16.1455026380922;
	Tue, 09 Feb 2016 05:59:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.209.22 with HTTP; Tue, 9 Feb 2016 05:59:01 -0800 (PST)
In-Reply-To: <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<201602060012.26728.luke@dashjr.org>
	<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
	<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
From: Yifu Guo <yifu@coinapex.com>
Date: Tue, 9 Feb 2016 08:59:01 -0500
Message-ID: <CAHcfU-W9vubmuRFSb-zZgdKdCvXdO9ttZtu9T2tNxWTHcsGaTA@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b47202892fc55052b56bae7
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,URIBL_SBL
	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, 10 Feb 2016 05:30:02 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 09 Feb 2016 13:59:43 -0000

--047d7b47202892fc55052b56bae7
Content-Type: text/plain; charset=UTF-8

Happy Lunar New Year Everyone!

Gavin,

> I suspect there ARE a significant percentage of un-maintained full
> nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for
> three reasons:


The notion of large set ( 30% to 40% ) of un-maintained full nodes are not
evident on the network. below is data based on a personal snap shot taken
around Dec, 2015. with the following assumptions.
1) nodes running non standard version strings are considered a preference
by the node operator and are not included.
2) nodes below 0.10 are counted as so called "un-maintained" even though
they also can be a choice of the node operator.

Satoshi:0.9.3, 105
Satoshi:0.8.6, 74
Satoshi:0.9.1, 49
Satoshi:0.9.2.1, 42
Satoshi:0.8.5, 39
Satoshi:0.8.1, 35
Satoshi:0.9.5, 14
Satoshi:0.8.3, 12
Satoshi:0.9.4, 10
Satoshi:0.9.99, 10
Satoshi:0.9.0, 5
Satoshi:0.9.2, 5
Satoshi:0.8.0, 4
Satoshi:0.8.99, 1
Satoshi:0.8.4, 1

There are 406 nodes total that falls under the un-maintained category,
which is below 10% of the network.
Luke also have some data here that shows similar results.
http://luke.dashjr.org/programs/bitcoin/files/charts/versions.txt

> The network could shrink by 60% and it would still have plenty of open
> connection slots


I'm afraid we have to agree to disagree if you think dropping support for
60% of the nodes on the network when rolling out an upgrade is the sane
default.

>
> > People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.


thousands of nodes?! where did you get this figure? who are these people?
*Please* elaborate.

> We could wait a year and pick up maybe 10 or 20% more.


I don't understand this statement at all, please explicate.

-- 
*Yifu Guo*
*"Life is an everlasting self-improvement."*

On Sat, Feb 6, 2016 at 10:37 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up.  As I said,
> I surveyed several of the biggest infrastructure providers and the btcd
> lead developer and they all agree "28 days is plenty of time."
>
> For individuals... why would it take somebody longer than 28 days to
> either download and restart their bitcoind, or to patch and then re-run
> (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?
>
> For the Bitcoin Core project:  I'm well aware of how long it takes to roll
> out new binaries, and 28 days is plenty of time.
>
> I suspect there ARE a significant percentage of un-maintained full nodes--
> probably 30 to 40%. Losing those nodes will not be a problem, for three
> reasons:
> 1) The network could shrink by 60% and it would still have plenty of open
> connection slots
> 2) People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.
> 3) We could wait a year and pick up maybe 10 or 20% more.
>
> I strongly disagree with the statement that there is no cost to a longer
> grace period. There is broad agreement that a capacity increase is needed
> NOW.
>
> To bring it back to bitcoin-dev territory:  are there any TECHNICAL
> arguments why an upgrade would take a business or individual longer than 28
> days?
>
>
> Responding to Luke's message:
>
> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>> wrote:
>> >> Blog post on a couple of the constants chosen:
>> >>   http://gavinandresen.ninja/seventyfive-twentyeight
>> >
>> > Can you put this in the BIP's Rationale section (which appears to be
>> mis-named
>> > "Discussion" in the current draft)?
>>
>
> I'll rename the section and expand it a little. I think standards
> documents like BIPs should be concise, though (written for implementors),
> so I'm not going to recreate the entire blog post there.
>
>
>> >
>> >> Signature operations in un-executed branches of a Script are not
>> counted
>> >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature
>> for a
>> >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the
>> top
>> >> of the execution stack, it is counted as one signature operation. If
>> it is
>> >> satisfied by the public key nearest the bottom of the execution stack,
>> it
>> >> is counted as twenty signature operations. Signature operations
>> involving
>> >> invalidly encoded signatures or public keys are not counted towards the
>> >> limit
>> >
>> > These seem like they will break static analysis entirely. That was a
>> noted
>> > reason for creating BIP 16 to replace BIP 12. Is it no longer a
>> concern? Would
>> > it make sense to require scripts to commit to the total accurate-sigop
>> count
>> > to fix this?
>>
>
> After implementing static counting and accurate counting... I was wrong.
> Accurate/dynamic counting/limiting is quick and simple and can be
> completely safe (the counting code can be told the limit and can
> "early-out" validation).
>
> I think making scripts commit to a total accurate sigop count is a bad
> idea-- it would make multisignature signing more complicated for zero
> benefit.  E.g. if you're circulating a partially signed transaction to that
> must be signed by 2 of 5 people, you can end up with a transaction that
> requires 2, 3, 4, or 5 signature operations to validate (depending on which
> public keys are used to do the signing).  The first signer might have no
> idea who else would sign and wouldn't know the accurate sigop count.
>
>
>> >
>> >> The amount of data hashed to compute signature hashes is limited to
>> >> 1,300,000,000 bytes per block.
>> >
>> > The rationale for this wasn't in your blog post. I assume it's based on
>> the
>> > current theoretical max at 1 MB blocks? Even a high-end PC would
>> probably take
>> > 40-80 seconds just for the hashing, however - maybe a lower limit would
>> be
>> > best?
>>
>
> It is slightly more hashing than was required to validate block number
> 364,422.
>
> There are a couple of advantages to a very high limit:
>
> 1) When the fork is over, special-case code for dealing with old blocks
> can be eliminated, because all old blocks satisfy the new limit.
>
> 2) More importantly, if the limit is small enough it might get hit by
> standard transactions, then block creation code (CreateNewBlock() /
> getblocktemplate / or some external transaction-assembling software) will
> have to solve an even more complicated bin-packing problem to optimize for
> fees paid.
>
> In practice, the 20,000 sigop limit will always be reached before
> MAX_BLOCK_SIGHASH.
>
>
>
>> >
>> >> Miners express their support for this BIP by ...
>> >
>> > But miners don't get to decide hardforks. How does the economy express
>> their
>> > support for it? What happens if miners trigger it without consent from
>> the
>> > economy?
>>
>
> "The economy" does support this.
>
>
>
>> >
>> > If you are intent on using the version bits to trigger the hardfork, I
>> suggest
>> > rephrasing this such that miners should only enable the bit when they
>> have
>> > independently confirmed economic support (this means implementations
>> need a
>> > config option that defaults to off).
>>
>
> Happy to add words about economic majority.
>
> Classic will not implement a command-line option (the act of running
> Classic is "I opt in"), but happy to add one for a pull request to Core,
> assuming Core would not see such a pull request as having any hostile
> intent.
>
>
> >
>> >> SPV (simple payment validation) wallets are compatible with this
>> change.
>> >
>> > Would prefer if this is corrected to "Light clients" or something.
>> Actual SPV
>> > wallets do not exist at this time, and would not be compatible with a
>> > hardfork.
>>
>
> Is there an explanation of SPV versus "Light Client" written somewhere
> more permanent than a reddit comment or forum post that I can point to?
>
>
>> >
>> >> In the short term, an increase is needed to continue the current
>> economic
>> >> policies with regards to fees and block space, matching market
>> expectations
>> >> and preventing market disruption.
>> >
>> > IMO this sentence is the most controversial part of your draft, and it
>> > wouldn't suffer a loss to remove it (or at least make it subjective).
>>
>
> Happy to remove.
>
>
>> > I would also prefer to see any hardfork:
>> >
>> > 1. Address at least the simple tasks on the hardfork wishlist (eg,
>> enable some
>> >    disabled opcodes; fix P2SH for N-of->15 multisig; etc).
>>
>
> Those would be separate BIPs. (according to BIP 1, smaller is better)
>
> After this 2MB bump, I agree we need to agree on a process for the next
> hard fork to avoid all of the unnecessary drama.
>
> > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
>> >    insecure.
>>
>
> I haven't been paying attention to all of the
> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
> mean. Is THAT written up somewhere?
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Happy Lunar New Year Everyone!<div><br></div><div>Gavin,<b=
r><div><br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex">&gt; I suspect there ARE a significa=
nt percentage of un-maintained full nodes-- probably 30 to 40%. Losing thos=
e nodes will not be a problem, for three reasons:</blockquote><div><br></di=
v><div>The notion of large set ( 30% to 40% ) of un-maintained full nodes a=
re not evident on the network. below is data based on a personal snap shot =
taken around Dec, 2015. with the following assumptions.</div><div>1) nodes =
running non standard version strings are considered a preference by the nod=
e operator and are not included.<br></div><div>2) nodes below 0.10 are coun=
ted as so called &quot;un-maintained&quot; even though they also can be a c=
hoice of the node operator.</div><div><br></div><div><div>Satoshi:0.9.3, 10=
5</div><div>Satoshi:0.8.6, 74</div><div>Satoshi:0.9.1, 49</div><div>Satoshi=
:0.9.2.1, 42</div><div>Satoshi:0.8.5, 39</div><div>Satoshi:0.8.1, 35</div><=
div>Satoshi:0.9.5, 14</div><div>Satoshi:0.8.3, 12</div><div>Satoshi:0.9.4, =
10</div><div>Satoshi:0.9.99, 10</div><div>Satoshi:0.9.0, 5</div><div>Satosh=
i:0.9.2, 5</div><div>Satoshi:0.8.0, 4</div><div>Satoshi:0.8.99, 1</div><div=
>Satoshi:0.8.4, 1</div></div><div><br></div><div>There are 406 nodes total =
that falls under the un-maintained category, which is below 10% of the netw=
ork.</div><div>Luke also have some data here that shows similar results.=C2=
=A0<a href=3D"http://luke.dashjr.org/programs/bitcoin/files/charts/versions=
.txt">http://luke.dashjr.org/programs/bitcoin/files/charts/versions.txt</a>=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex">&gt; The network could shrink by 60% =
and it would still have plenty of open connection slots</blockquote><div><b=
r></div><div>I&#39;m afraid we have to agree to disagree if you think dropp=
ing support for 60% of the nodes on the network when rolling out an upgrade=
 is the sane default.</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><br>&gt; People are committing =
to spinning up thousands of supports-2mb-nodes during the grace period.</bl=
ockquote><div><br></div><div>thousands of nodes?! where did you get this fi=
gure? who are these people? <i><b>Please</b></i> elaborate.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex">&gt; We could wait a year and pick up maybe 10 or 20%=
 more.</blockquote></div><div><br></div><div>I don&#39;t understand this st=
atement at all, please=C2=A0explicate.</div><div><br></div><div>--=C2=A0<br=
><div class=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(1=
36,136,136)"><font face=3D"garamond, serif" size=3D"4"><b>Yifu Guo</b></fon=
t></span><div><font face=3D"verdana, sans-serif"><div style=3D"font-size:13=
px"><font size=3D"1" color=3D"#333333"><i>&quot;Life is an everlasting self=
-improvement.&quot;</i></font></div></font></div></div></div><div class=3D"=
gmail_extra"><br><div class=3D"gmail_quote">On Sat, Feb 6, 2016 at 10:37 AM=
, Gavin Andresen via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color=
:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr=
">Responding to &quot;28 days is not long enough&quot; :<div><br></div><div=
>I keep seeing this claim made with no evidence to back it up.=C2=A0 As I s=
aid, I surveyed several of the biggest infrastructure providers and the btc=
d lead developer and they all agree &quot;28 days is plenty of time.&quot;<=
/div><div><br></div><div>For individuals... why would it take somebody long=
er than 28 days to either download and restart their bitcoind, or to patch =
and then re-run (the patch can be a one-line change MAX_BLOCK_SIZE from 100=
0000 to 2000000)?</div><div><br></div><div>For the Bitcoin Core project: =
=C2=A0I&#39;m well aware of how long it takes to roll out new binaries, and=
 28 days is plenty of time.</div><div><br></div><div>I suspect there ARE a =
significant percentage of un-maintained full nodes-- probably 30 to 40%. Lo=
sing those nodes will not be a problem, for three reasons:</div><div>1) The=
 network could shrink by 60% and it would still have plenty of open connect=
ion slots</div><div>2) People are committing to spinning up thousands of su=
pports-2mb-nodes during the grace period.</div><div>3) We could wait a year=
 and pick up maybe 10 or 20% more.</div><div><br></div><div>I strongly disa=
gree with the statement that there is no cost to a longer grace period. The=
re is broad agreement that a capacity increase is needed NOW.</div><div><br=
></div><div>To bring it back to bitcoin-dev territory: =C2=A0are there any =
TECHNICAL arguments why an upgrade would take a business or individual long=
er than 28 days?</div><div><br></div><div><br></div><div>Responding to Luke=
&#39;s message:</div><div><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div><div>On Sat, Feb =
6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev=
 wrote:<br>
&gt;&gt; Blog post on a couple of the constants chosen:<br>
&gt;&gt;=C2=A0 =C2=A0<a href=3D"http://gavinandresen.ninja/seventyfive-twen=
tyeight" rel=3D"noreferrer" target=3D"_blank">http://gavinandresen.ninja/se=
ventyfive-twentyeight</a><br>
&gt;<br>
&gt; Can you put this in the BIP&#39;s Rationale section (which appears to =
be mis-named<br>
&gt; &quot;Discussion&quot; in the current draft)?<br></div></div></blockqu=
ote><div><br></div></span><div>I&#39;ll rename the section and expand it a =
little. I think standards documents like BIPs should be concise, though (wr=
itten for implementors), so I&#39;m not going to recreate the entire blog p=
ost there.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><di=
v>
&gt;<br>
&gt;&gt; Signature operations in un-executed branches of a Script are not c=
ounted<br>
&gt;&gt; OP_CHECKMULTISIG evaluations are counted accurately; if the signat=
ure for a<br>
&gt;&gt; 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest t=
he top<br>
&gt;&gt; of the execution stack, it is counted as one signature operation. =
If it is<br>
&gt;&gt; satisfied by the public key nearest the bottom of the execution st=
ack, it<br>
&gt;&gt; is counted as twenty signature operations. Signature operations in=
volving<br>
&gt;&gt; invalidly encoded signatures or public keys are not counted toward=
s the<br>
&gt;&gt; limit<br>
&gt;<br>
&gt; These seem like they will break static analysis entirely. That was a n=
oted<br>
&gt; reason for creating BIP 16 to replace BIP 12. Is it no longer a concer=
n? Would<br>
&gt; it make sense to require scripts to commit to the total accurate-sigop=
 count<br>
&gt; to fix this?<br></div></div></blockquote><div><br></div></span><div>Af=
ter implementing static counting and accurate counting... I was wrong. Accu=
rate/dynamic counting/limiting is quick and simple and can be completely sa=
fe (the counting code can be told the limit and can &quot;early-out&quot; v=
alidation).</div><div><br></div><div>I think making scripts commit to a tot=
al accurate sigop count is a bad idea-- it would make multisignature signin=
g more complicated for zero benefit.=C2=A0 E.g. if you&#39;re circulating a=
 partially signed transaction to that must be signed by 2 of 5 people, you =
can end up with a transaction that requires 2, 3, 4, or 5 signature operati=
ons to validate (depending on which public keys are used to do the signing)=
.=C2=A0 The first signer might have no idea who else would sign and wouldn&=
#39;t know the accurate sigop count.</div><span class=3D""><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div><div>
&gt;<br>
&gt;&gt; The amount of data hashed to compute signature hashes is limited t=
o<br>
&gt;&gt; 1,300,000,000 bytes per block.<br>
&gt;<br>
&gt; The rationale for this wasn&#39;t in your blog post. I assume it&#39;s=
 based on the<br>
&gt; current theoretical max at 1 MB blocks? Even a high-end PC would proba=
bly take<br>
&gt; 40-80 seconds just for the hashing, however - maybe a lower limit woul=
d be<br>
&gt; best?<br></div></div></blockquote><div><br></div></span><div>It is sli=
ghtly more hashing than was required to validate block number 364,422.</div=
><div><br></div><div>There are a couple of advantages to a very high limit:=
</div><div><br></div><div>1) When the fork is over, special-case code for d=
ealing with old blocks can be eliminated, because all old blocks satisfy th=
e new limit.</div><div><br></div><div>2) More importantly, if the limit is =
small enough it might get hit by standard transactions, then block creation=
 code (CreateNewBlock() / getblocktemplate / or some external transaction-a=
ssembling software) will have to solve an even more complicated bin-packing=
 problem to optimize for fees paid.</div><div><br></div><div>In practice, t=
he 20,000 sigop limit will always be reached before MAX_BLOCK_SIGHASH.</div=
><span class=3D""><div><br></div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><di=
v>
&gt;<br>
&gt;&gt; Miners express their support for this BIP by ...<br>
&gt;<br>
&gt; But miners don&#39;t get to decide hardforks. How does the economy exp=
ress their<br>
&gt; support for it? What happens if miners trigger it without consent from=
 the<br>
&gt; economy?<br></div></div></blockquote><div><br></div></span><div>&quot;=
The economy&quot; does support this.</div><span class=3D""><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div><div>
&gt;<br>
&gt; If you are intent on using the version bits to trigger the hardfork, I=
 suggest<br>
&gt; rephrasing this such that miners should only enable the bit when they =
have<br>
&gt; independently confirmed economic support (this means implementations n=
eed a<br>
&gt; config option that defaults to off).<br></div></div></blockquote><div>=
<br></div></span><div>Happy to add words about economic majority.</div><div=
><br></div><div>Classic will not implement a command-line option (the act o=
f running Classic is &quot;I opt in&quot;), but happy to add one for a pull=
 request to Core, assuming Core would not see such a pull request as having=
 any hostile intent.</div><span class=3D""><div><br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div><div>
&gt;<br>
&gt;&gt; SPV (simple payment validation) wallets are compatible with this c=
hange.<br>
&gt;<br>
&gt; Would prefer if this is corrected to &quot;Light clients&quot; or some=
thing. Actual SPV<br>
&gt; wallets do not exist at this time, and would not be compatible with a<=
br>
&gt; hardfork.<br></div></div></blockquote><div><br></div></span><div>Is th=
ere an explanation of SPV versus &quot;Light Client&quot; written somewhere=
 more permanent than a reddit comment or forum post that I can point to?</d=
iv><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div><div>
&gt;<br>
&gt;&gt; In the short term, an increase is needed to continue the current e=
conomic<br>
&gt;&gt; policies with regards to fees and block space, matching market exp=
ectations<br>
&gt;&gt; and preventing market disruption.<br>
&gt;<br>
&gt; IMO this sentence is the most controversial part of your draft, and it=
<br>
&gt; wouldn&#39;t suffer a loss to remove it (or at least make it subjectiv=
e).<br></div></div></blockquote><div><br></div></span><div>Happy to remove.=
</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
&gt; I would also prefer to see any hardfork:<br>
&gt;<br>
&gt; 1. Address at least the simple tasks on the hardfork wishlist (eg, ena=
ble some<br>
&gt;=C2=A0 =C2=A0 disabled opcodes; fix P2SH for N-of-&gt;15 multisig; etc)=
.<br></div></div></blockquote><div><br></div></span><div>Those would be sep=
arate BIPs. (according to BIP 1, smaller is better)</div><div><br></div><di=
v>After this 2MB bump, I agree we need to agree on a process for the next h=
ard fork to avoid all of the unnecessary drama.</div><span class=3D""><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-sty=
le:solid;padding-left:1ex"><div><div>
&gt; 2. Be deployed as a soft-hardfork so as not to leave old nodes entirel=
y<br>
&gt;=C2=A0 =C2=A0 insecure.</div></div></blockquote></span></div><div class=
=3D"gmail_extra"><br></div>I haven&#39;t been paying attention to all of th=
e &quot;soft-hardfork/hard-softfork/etc&quot; terminology so have no idea w=
hat you mean. Is THAT written up somewhere?<span class=3D""><font color=3D"=
#888888"><br clear=3D"all"><div><br></div>-- <br><div><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div>--<br>Gavin Andresen<br></div><div><br></div></div><=
/div></div></div>
</font></span></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br></blockquote></div>
</div></div></div></div>

--047d7b47202892fc55052b56bae7--