path: root/95/28b35f732acfcf288c5707e6a9abc73702f1f1

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--