path: root/b6/00f8ea29b277cb7c14d34cb1e6166a029b849b

Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0D21613B7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 15:37:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com
	[209.85.217.178])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 336F6112
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  6 Feb 2016 15:37:32 +0000 (UTC)
Received: by mail-lb0-f178.google.com with SMTP id bc4so63971944lbc.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 06 Feb 2016 07:37:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=KbrdUpyxGsnQIccEzkQXn4pOYCvgHife7gU59eF0wwo=;
	b=coui0G7rkgT8OkKM6bduyUoeLslRBz2ZlY0wdJbAWvzC3XvUuv3FFFz5CM2Cwud6EW
	eqnPCpcdO5BdaYrGklLhRhdaeXVdDg50f+g0DNxOSYr5L2Xa7Ia5ln75Xyo6uu4BaSWu
	AH7hU/CVZRJVGJbMl5zMDWOnfMtQfdhewkoJyJGrUaeOfqqS/KdnmQcU75bqAJWBmjL0
	QtAdJWYrYaZbLpjk6JoiUeGE9qRapDqjeFq8KkRLTmXOKOL276qOX1V7q5u7pIltY8st
	cKXd0qLneLMpOJebwFUeJlL1wbvw9RaFylsk/i2jNkCRvX8dNFXyLPTsUt1FBsHNIq54
	JI5w==
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:date
	:message-id:subject:from:to:cc:content-type;
	bh=KbrdUpyxGsnQIccEzkQXn4pOYCvgHife7gU59eF0wwo=;
	b=fxbr/hdzW1Wvk5ygmMSJA3x9v2X29nXnZf/UXopAEQueJAgiNcx/MsfwxyxIdP6jyX
	8ot7A0f3igRis+ZBmusO2OZa0+g/wiw8DToffEsrXQlzAYJd+MFHCjX/D5SFT5EcoKKL
	Gk/GnJ/Y9i9Koll/zwH5yN/WbkcKDgQlk45H36S3IIYXxjIdbVxrbsb/fgzS8qGgHpsa
	fkx/moY/yfaTUhvM2wH5ahSJxcP8C2U3foErq0R1uoBe5YSf5ludM/j8GFXZjHDl5H/b
	yG8z8qg4HlmpEIUEHYptE8Nz9vzWpjs3wDZZBwnlfkQIpCNwWbQ6/Qz3TZXHrKeh0s4r
	3IrQ==
X-Gm-Message-State: AG10YOQZWgDble/pqE5YAB/wawUgXWn/eaeZ97l4bEKnu68k80zmAHvPoYYoHtCNOiS/MlvDfMAcx1XdgrnKgw==
MIME-Version: 1.0
X-Received: by 10.112.171.134 with SMTP id au6mr3664510lbc.27.1454773050409;
	Sat, 06 Feb 2016 07:37:30 -0800 (PST)
Received: by 10.25.206.68 with HTTP; Sat, 6 Feb 2016 07:37:30 -0800 (PST)
In-Reply-To: <CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<201602060012.26728.luke@dashjr.org>
	<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
Date: Sat, 6 Feb 2016 10:37:30 -0500
Message-ID: <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a11c376dce60cc1052b1bbe2a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	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: Sat, 06 Feb 2016 15:40:53 +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: Sat, 06 Feb 2016 15:37:34 -0000

--001a11c376dce60cc1052b1bbe2a
Content-Type: text/plain; charset=UTF-8

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

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

<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 u=
p.=C2=A0 As I said, I surveyed several of the biggest infrastructure provid=
ers and the btcd lead developer and they all agree &quot;28 days is plenty =
of time.&quot;</div><div><br></div><div>For individuals... why would it tak=
e somebody longer than 28 days to either download and restart their bitcoin=
d, or to patch and then re-run (the patch can be a one-line change MAX_BLOC=
K_SIZE from 1000000 to 2000000)?</div><div><br></div><div>For the Bitcoin C=
ore 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%. Losing those nodes will not be a problem, for three reasons:</di=
v><div>1) The network could shrink by 60% and it would still have plenty of=
 open connection slots</div><div>2) People are committing to spinning up th=
ousands of supports-2mb-nodes during the grace period.</div><div>3) We coul=
d wait a year and pick up maybe 10 or 20% more.</div><div><br></div><div>I =
strongly disagree with the statement that there is no cost to a longer grac=
e period. There is broad agreement that a capacity increase is needed NOW.<=
/div><div><br></div><div>To bring it back to bitcoin-dev territory: =C2=A0a=
re there any TECHNICAL arguments why an upgrade would take a business or in=
dividual longer than 28 days?</div><div><br></div><div><br></div><div>Respo=
nding to Luke&#39;s message:</div><div><br></div><div class=3D"gmail_extra"=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div class=3D""><div class=3D"=
h5">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">bitcoin-dev@li=
sts.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><div>I&#39;ll rename the section and expand it a little.=
 I think standards documents like BIPs should be concise, though (written f=
or implementors), so I&#39;m not going to recreate the entire blog post the=
re.</div><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 class=3D""><div class=3D"h5=
">
&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><div>After imp=
lementing static counting and accurate counting... I was wrong. Accurate/dy=
namic counting/limiting is quick and simple and can be completely safe (the=
 counting code can be told the limit and can &quot;early-out&quot; validati=
on).</div><div><br></div><div>I think making scripts commit to a total accu=
rate sigop count is a bad idea-- it would make multisignature signing more =
complicated for zero benefit.=C2=A0 E.g. if you&#39;re circulating a partia=
lly 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).=C2=A0=
 The first signer might have no idea who else would sign and wouldn&#39;t k=
now the accurate sigop count.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div c=
lass=3D""><div class=3D"h5">
&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><div>It is slightly m=
ore 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 dealing =
with old blocks can be eliminated, because all old blocks satisfy the new l=
imit.</div><div><br></div><div>2) More importantly, if the limit is small e=
nough it might get hit by standard transactions, then block creation code (=
CreateNewBlock() / getblocktemplate / or some external transaction-assembli=
ng software) will have to solve an even more complicated bin-packing proble=
m to optimize for fees paid.</div><div><br></div><div>In practice, the 20,0=
00 sigop limit will always be reached before MAX_BLOCK_SIGHASH.</div><div><=
br></div><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 class=3D""><div class=3D"h5=
">
&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><div>&quot;The eco=
nomy&quot; does support this.</div><div><br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex"><div class=3D""><div class=3D"h5">
&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><div>Happy to add words about economic majority.</div><div><br></=
div><div>Classic will not implement a command-line option (the act of runni=
ng Classic is &quot;I opt in&quot;), but happy to add one for a pull reques=
t to Core, assuming Core would not see such a pull request as having any ho=
stile intent.</div><div><br></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);border-left-style:solid;padding-left:1ex"><div clas=
s=3D""><div class=3D"h5">
&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><div>Is there an =
explanation of SPV versus &quot;Light Client&quot; written somewhere more p=
ermanent than a reddit comment or forum post that I can point to?</div><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 class=3D""><div class=3D"h5">
&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><div>Happy to remove.</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 class=3D""><div class=3D"h5">
&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><div>Those would be separate B=
IPs. (according to BIP 1, smaller is better)</div><div><br></div><div>After=
 this 2MB bump, I agree we need to agree on a process for the next hard for=
k to avoid all of the unnecessary drama.</div><div><br></div><blockquote cl=
ass=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:1e=
x"><div class=3D""><div class=3D"h5">
&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></div><div class=3D"gma=
il_extra"><br></div>I haven&#39;t been paying attention to all of the &quot=
;soft-hardfork/hard-softfork/etc&quot; terminology so have no idea what you=
 mean. Is THAT written up somewhere?<br clear=3D"all"><div><br></div>-- <br=
><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div=
>--<br>Gavin Andresen<br></div><div><br></div></div></div></div></div>
</div></div>

--001a11c376dce60cc1052b1bbe2a--