path: root/09/1da3471c50368a665004eaad763a6c1afaac40

Return-Path: <asperous2@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1D052F0B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 Sep 2015 07:54:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
	[209.85.223.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB5F210C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 Sep 2015 07:54:08 +0000 (UTC)
Received: by ioii196 with SMTP id i196so15049312ioi.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 04 Sep 2015 00:54:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:content-type;
	bh=DNo9RV5fKKRpZZDsMgWVqzx/J8MFbetWgDA8tHwotkA=;
	b=fWXWi0Qhz+5W1mGrpsEaPw65GoOQYcaxWY7C5RyYcuiXz6brXwT0YbP3HBn+xfOlda
	s6XWOt6wOVJK/+IKcX4hqwYGKMxj3ctOy2J1SJucBAFZtrPRSjCr7UbZN9/9Zg/LdOu9
	qmwHD/7Pl9Ulm5CbBZEXnpPUMprTe/VfkyFylZFof6ejy7fHDMNypYyQ8Hq/wMapE/jG
	vw/Opxl3+xKNVf7adn6sVEFZO0WvHRLguqbXqYSS4zyZVg2RJOJk/AdEraaCabc6mJYw
	75lF+jNDAPsVHa2PhHLI6yO69qw0mtqSiFsgx61ZyNuzuXCNEunYmAAH+Gf2bN4jGGeJ
	Xuag==
X-Received: by 10.107.166.139 with SMTP id p133mr4435748ioe.113.1441353248336; 
	Fri, 04 Sep 2015 00:54:08 -0700 (PDT)
MIME-Version: 1.0
Sender: asperous2@gmail.com
Received: by 10.50.3.33 with HTTP; Fri, 4 Sep 2015 00:53:48 -0700 (PDT)
In-Reply-To: <CAE-z3OVd6+ncvJBwusSbcMTG6xaRxsboH3ru_zQXpbu2wW_Zng@mail.gmail.com>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
	<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
	<CAE-z3OVd6+ncvJBwusSbcMTG6xaRxsboH3ru_zQXpbu2wW_Zng@mail.gmail.com>
From: Andy Chase <theandychase@gmail.com>
Date: Fri, 4 Sep 2015 00:53:48 -0700
X-Google-Sender-Auth: nG6CUOX7uXzlxoyuLqgjyWIzPbg
Message-ID: <CAAxp-m93s5qDrs+1OHeSog+9=HV=XKs14Vs3jf4RdqSR9tA8xQ@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>, jgarzik@gmail.com, 
	bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1141ef3c5cf440051ee73434
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,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
Subject: Re: [bitcoin-dev] BIP 100 specification
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: Fri, 04 Sep 2015 07:54:10 -0000

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

The 32Mb limit is here:
https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25

It's to keep the message size small enough that messages can be serialized
in memory.

Jeff if you decide to lift the 32MB limit (you really should, unless your
plan is to potentially hard force another Blocksize discussion again which
might be okay). I suggest having the 32MB ceiling auto-raise according to a
exponential factor (1.5?) starting 1 year from now.

Basically hard limit ceiling 2016-2017: 32 MB
Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB

The factor could be 2 like BIP-101 but I imagine you will want to be more
conservative. The delay time could also be longer if you think it will take
longer to fix the message size issue across all implementations.


On Thu, Sep 3, 2015 at 4:59 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>    1.
>>
>>    hardLimit floats within the range 1-32M, inclusive.
>>
>>
>>
> Does the 32MB limit actually still exist anywhere in the code?  In effect,
> it is re-instating a legacy limitation.
>
> The message size limit is to minimize the storage required per peer.  If a
> 32MB block size is required, then each network input buffer must be at
> least 32MB. This makes it harder for a node to support a large number of
> peers.
>
> There is no reason why a single message is used for each block.  Using the
> merkleblock message (or a different dedicated message), it would be
> possible to send messages which only contain part of a block and have a
> limited maximum size.
>
> This would allow receiving parts of a block from multiple sources.
>
> This is a separate issue but should be considered if moving past 32MB
> block sizes (or maybe as a later protocol change).
>
>
>>
>>    1. Changing hardLimit is accomplished by encoding a proposed value
>>    within a block's coinbase scriptSig.
>>       1. Votes refer to a byte value, encoded within the pattern
>>       "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If
>>       there is more than one match with with pattern, the first match is counted.
>>
>> Is there a need for byte resolution?  Using MB resolution would use up
> much fewer bytes in the coinbase.
>
> Even with the +/- 20% rule, miners could vote for the nearest MB.  Once
> the block size exceeds 5MB, then there is enough resolution anyway.
>
>
>>    1. Absent/invalid votes and votes below minimum cap (1M) are counted
>>       as 1M votes. Votes above the maximum cap (32M) are counted as 32M votes.
>>
>>
> I think abstains should count for the status quo.  Votes which are out of
> range should be clamped.
>
> Having said that, if core supports the change, then most miners will
> probably vote one way or another.
>
> > New hardLimit is the median of the followings:
> > min(current hardLimit * 1.2, 20-percentile)
> > max(current hardLimit / 1.2, 80-percentile)
> > current hardLimit
>
> I think this is unclear, though mathematically exact.
>
> Sort the votes for the last 12,000 blocks from lowest to highest.
>
> Blocks which don't have a vote are considered a vote for the status quo.
>
> Votes are limited to +/- 20% of the current value.  Votes that are out of
> range are considered to vote for the nearest in range value.
>
> The raise value is defined as the vote for the 2400th highest block (20th
> percentile).
> The lower value  is defined as the vote for the 9600th highest block (80th
> percentile).
>
> If the raise value is higher than the status quo, then the new limit is
> set to the raise value.
> If the lower value is lower than the status quo, then the new limit is set
> to the lower value.
> Otherwise, the size limit is unchanged.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">The 32Mb limit is here:=C2=A0<a href=3D"https://github.com=
/bitcoin/bitcoin/blob/master/src/serialize.h#L25">https://github.com/bitcoi=
n/bitcoin/blob/master/src/serialize.h#L25</a><div><br></div><div>It&#39;s t=
o keep the message size small enough that messages can be serialized in mem=
ory.</div><div><br></div><div>Jeff if you decide to lift the 32MB limit (yo=
u really should, unless your plan is to potentially hard force another Bloc=
ksize discussion again which might be okay). I suggest having the 32MB ceil=
ing auto-raise according to a exponential factor (1.5?) starting 1 year fro=
m now.</div><div><br></div><div>Basically hard limit ceiling 2016-2017: 32 =
MB</div><div>Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB</div>=
<div><br></div><div>The factor could be 2 like BIP-101 but I imagine you wi=
ll want to be more conservative. The delay time could also be longer if you=
 think it will take longer to fix the message size issue across all impleme=
ntations.</div><div><br></div></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Thu, Sep 3, 2015 at 4:59 AM, Tier Nolan via bitcoin-d=
ev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Thu, Se=
p 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br></span><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif"><ol><li=
>
<pre>hardLimit floats within the range 1-32M, inclusive.</pre></li></ol></d=
iv></blockquote><div><br></div></span><div>Does the 32MB limit actually sti=
ll exist anywhere in the code?=C2=A0 In effect, it is re-instating a legacy=
 limitation.<br><br></div><div>The message size limit is to minimize the st=
orage required per peer.=C2=A0 If a 32MB block size is required, then each =
network input buffer must be at least 32MB. This makes it harder for a node=
 to support a large number of peers.<br><br></div><div>There is no reason w=
hy a single message is used for each block.=C2=A0 Using the merkleblock mes=
sage (or a different dedicated message), it would be possible to send messa=
ges which only contain part of a block and have a limited maximum size.<br>=
<br></div><div>This would allow receiving parts of a block from multiple so=
urces.=C2=A0 <br><br></div><div>This is a separate issue but should be cons=
idered if moving past 32MB block sizes (or maybe as a later protocol change=
).<br></div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div style=3D"font-size:10pt;font-family:Verdana,Genev=
a,sans-serif"><ol><li><span style=3D"white-space:pre-wrap">Changing hardLim=
it is accomplished by encoding a proposed value within a block&#39;s coinba=
se scriptSig.</span></li>
<ol>
<li><span style=3D"white-space:pre-wrap">Votes refer to a byte value, encod=
ed within the pattern &quot;/BV\d+/&quot; Example: /BV8000000/ votes for 8,=
000,000 byte hardLimit. </span><span style=3D"white-space:pre-wrap;text-dec=
oration:underline">If there is more than one match with with pattern, the f=
irst match is counted.</span></li></ol></ol></div></blockquote></span><div>=
Is there a need for byte resolution?=C2=A0 Using MB resolution would use up=
 much fewer bytes in the coinbase.<br><br></div><div>Even with the +/- 20% =
rule, miners could vote for the nearest MB.=C2=A0 Once the block size excee=
ds 5MB, then there is enough resolution anyway.<br></div><span class=3D""><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=
=3D"font-size:10pt;font-family:Verdana,Geneva,sans-serif"><ol><ol>
<li><span style=3D"white-space:pre-wrap">Absent/invalid votes and votes bel=
ow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (3=
2M) are counted as 32M votes.</span></li></ol></ol></div></blockquote><div>=
<br></div></span><div>I think abstains should count for the status quo.=C2=
=A0 Votes which are out of range should be clamped.<br><br></div><div>Havin=
g said that, if core supports the change, then most miners will probably vo=
te one way or another.<span class=3D""><br><br>&gt;<span style=3D"white-spa=
ce:pre-wrap"> New hardLimit is the median of the followings:</span><span st=
yle=3D"white-space:pre-wrap"><br>&gt;     m</span><span style=3D"white-spac=
e:pre-wrap">in(current hardLimit * 1.2, 20-percentile)</span><span style=3D=
"white-space:pre-wrap"><br>&gt;     max(current hardLimit / 1.2, 80-percent=
ile)</span><span style=3D"white-space:pre-wrap"><br>&gt;     current hardLi=
mit</span><span style=3D"text-decoration:underline;white-space:pre-wrap"></=
span><span style=3D"text-decoration:underline;white-space:pre-wrap"></span>=
<br><br></span></div><div>I think this is unclear, though mathematically ex=
act.<br></div><div><br></div>Sort the votes for the last 12,000 blocks from=
 lowest to highest.=C2=A0 <br><br>Blocks which don&#39;t have a vote are co=
nsidered a vote for the status quo.<br><br></div><div class=3D"gmail_quote"=
>Votes are limited to +/- 20% of the current value.=C2=A0 Votes that are ou=
t of range are considered to vote for the nearest in range value.<br></div>=
<br><div class=3D"gmail_quote">The raise value is defined as the vote for t=
he 2400th highest block (20th percentile).<br></div><div class=3D"gmail_quo=
te">The lower value=C2=A0 is defined as the vote for the 9600th highest blo=
ck (80th percentile).<br><br></div><div class=3D"gmail_quote">If the raise =
value is higher than the status quo, then the new limit is set to the raise=
 value.<br></div><div class=3D"gmail_quote">If the lower value is lower tha=
n the status quo, then the new limit is set to the lower value.<br></div><d=
iv class=3D"gmail_quote">Otherwise, the size limit is unchanged.<br></div><=
/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>
<br></blockquote></div><br></div>

--001a1141ef3c5cf440051ee73434--