path: root/46/765611b72bc0c2e532c96e356799ea9bc715bc

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F06CE66
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 16:35:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com
	[209.85.212.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF84C1E8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  3 Sep 2015 16:35:24 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so4917032wic.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 03 Sep 2015 09:35:23 -0700 (PDT)
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=kyTeM+DHgAKs7+L3wH1uT7rWa5PS61o0r7lPHqYB86w=;
	b=AjSZyW2m09oBhR7sheNoJAiwlBsnj4fSZWR4PDqsztB6kYXY7/4UoPSj1O3sFsUfi7
	zbWGC7Wz1xDo3/BPa1aLJpoYJwv46ayhTcBaKYe+g9Az0YX2yDc7L3FvU9M37oJ4b+Ol
	xfhwmPBmZZCykP11GC6LPMQiuvExUHvckKG+y2f2BmiZyHxLchxMr3DNu8cN4lAT/1wV
	cNnuiDz/AcwS30bze2Y8+z4DprtpJzHBZwVyX7YWhKkR6kCKiElrSWHPGkFa1Oa5Bova
	NEO4G1kPc9yKa+aC8TaXl1avmK9HBB5dEN3c0qTW7eRcNGDItwnAKT/0y2UXE/hMrY5y
	5vTQ==
MIME-Version: 1.0
X-Received: by 10.180.87.1 with SMTP id t1mr15720367wiz.33.1441298123658; Thu,
	03 Sep 2015 09:35:23 -0700 (PDT)
Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 09:35:23 -0700 (PDT)
In-Reply-To: <301aa5f682f8aa408b9f6f4618095fe2@xbt.hk>
References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com>
	<e54e93e519d776262f9c0f4ae23f54fb@xbt.hk>
	<CAE-z3OVd6+ncvJBwusSbcMTG6xaRxsboH3ru_zQXpbu2wW_Zng@mail.gmail.com>
	<301aa5f682f8aa408b9f6f4618095fe2@xbt.hk>
Date: Thu, 3 Sep 2015 12:35:23 -0400
Message-ID: <CADm_WcaJYogJWeQ0kkADgYMS7=H9f60Y4thr_XT-thROyYfg2w@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: jl2012@xbt.hk
Content-Type: multipart/alternative; boundary=f46d044481afad1b83051eda5e5c
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
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.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: Thu, 03 Sep 2015 16:35:27 -0000

--f46d044481afad1b83051eda5e5c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Take a look at the latest update:

- swiped Tier Nolan verbiage, which I agree was usefully more clear
- added 'M' suffix and removed 'V' from coinbase scriptSig


On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 1. I think there is no need to have resolution at byte level, while
> resolution at MB level is not enough. kB would be a better choice.
>
> 2. In my specification a v4 block without a vote is invalid, so there is
> no need to consider absent or invalid votes
>
> 3. We should allow miners to explicitly vote for the status quo, so they
> don't need to change the coinbase vote every time the size is changed. Th=
ey
> may indicate it by /BV/ in the coinbase, and we should look for the first
> "/BVd*/" instead of "/BVd+/"
>
> 4. Alternatively, miners may vote in different styles: /BV1234567/,
> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5M=
B,
> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
>
> Tier Nolan via bitcoin-dev =E6=96=BC 2015-09-03 07:59 =E5=AF=AB=E5=88=B0:
>
>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> *
>>>
>>> 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).
>>
>> * Changing hardLimit is accomplished by encoding a proposed value
>>> within a block's coinbase scriptSig.
>>>
>>> * Votes refer to a byte value, encoded within the pattern "/BVd+/"
>>> 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.
>>
>> * 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Take a look at the latest update:<div><br></div><div>- swi=
ped Tier Nolan verbiage, which I agree was usefully more clear</div><div>- =
added &#39;M&#39; suffix and removed &#39;V&#39; from coinbase scriptSig</d=
iv><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">On Thu, Sep 3, 2015 at 12:32 PM, 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>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">1. I think there is no need to have resoluti=
on at byte level, while resolution at MB level is not enough. kB would be a=
 better choice.<br>
<br>
2. In my specification a v4 block without a vote is invalid, so there is no=
 need to consider absent or invalid votes<br>
<br>
3. We should allow miners to explicitly vote for the status quo, so they do=
n&#39;t need to change the coinbase vote every time the size is changed. Th=
ey may indicate it by /BV/ in the coinbase, and we should look for the firs=
t &quot;/BVd*/&quot; instead of &quot;/BVd+/&quot;<br>
<br>
4. Alternatively, miners may vote in different styles: /BV1234567/, /BV1500=
K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, the la=
st one is 3MB. The pattern is &quot;/BV(\d+[KM]?)?/&quot;<br>
<br>
Tier Nolan via bitcoin-dev =E6=96=BC 2015-09-03 07:59 =E5=AF=AB=E5=88=B0:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><span class=3D"">
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 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>
<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
*<span class=3D""><br>
<br>
hardLimit floats within the range 1-32M, inclusive.<br>
</span></blockquote><span class=3D"">
<br>
Does the 32MB limit actually still exist anywhere in the code?=C2=A0 In<br>
effect, it is re-instating a legacy limitation.<br>
<br>
The message size limit is to minimize the storage required per peer.<br>
If a 32MB block size is required, then each network input buffer must<br>
be at least 32MB. This makes it harder for a node to support a large<br>
number of peers.<br>
<br>
There is no reason why a single message is used for each block.=C2=A0 Using=
<br>
the merkleblock message (or a different dedicated message), it would<br>
be possible to send messages which only contain part of a block and<br>
have a limited maximum size.<br>
<br>
This would allow receiving parts of a block from multiple sources.<br>
<br>
This is a separate issue but should be considered if moving past 32MB<br>
block sizes (or maybe as a later protocol change).<br>
<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
* Changing hardLimit is accomplished by encoding a proposed value<span clas=
s=3D""><br>
within a block&#39;s coinbase scriptSig.<br>
<br></span>
* Votes refer to a byte value, encoded within the pattern &quot;/BVd+/&quot=
;<span class=3D""><br>
Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is<br>
more than one match with with pattern, the first match is counted.<br>
</span></blockquote><span class=3D"">
<br>
Is there a need for byte resolution?=C2=A0 Using MB resolution would use up=
<br>
much fewer bytes in the coinbase.<br>
<br>
Even with the +/- 20% rule, miners could vote for the nearest MB.<br>
Once the block size exceeds 5MB, then there is enough resolution<br>
anyway.<br>
<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
* Absent/invalid votes and votes below minimum cap (1M) are<div><div class=
=3D"h5"><br>
counted as 1M votes. Votes above the maximum cap (32M) are counted<br>
as 32M votes.<br>
</div></div></blockquote><div><div class=3D"h5">
<br>
I think abstains should count for the status quo.=C2=A0 Votes which are out=
<br>
of range should be clamped.<br>
<br>
Having said that, if core supports the change, then most miners will<br>
probably vote one way or another.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
New hardLimit is the median of the followings:<br>
min(current hardLimit * 1.2, 20-percentile)<br>
max(current hardLimit / 1.2, 80-percentile)<br>
current hardLimit<br>
</blockquote>
<br>
I think this is unclear, though mathematically exact.<br>
<br>
Sort the votes for the last 12,000 blocks from lowest to highest.<br>
<br>
Blocks which don&#39;t have a vote are considered a vote for the status<br>
quo.<br>
<br>
Votes are limited to +/- 20% of the current value.=C2=A0 Votes that are out=
<br>
of range are considered to vote for the nearest in range value.<br>
<br>
The raise value is defined as the vote for the 2400th highest block<br>
(20th percentile).<br>
<br>
The lower value=C2=A0 is defined as the vote for the 9600th highest block<b=
r>
(80th percentile).<br>
<br>
If the raise value is higher than the status quo, then the new limit<br>
is set to the raise value.<br>
<br>
If the lower value is lower than the status quo, then the new limit is<br>
set to the lower value.<br>
<br>
Otherwise, the size limit is unchanged.<br>
<br></div></div><span class=3D"">
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</span></blockquote><div class=3D"HOEnZb"><div class=3D"h5">
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</div></div></blockquote></div><br></div>

--f46d044481afad1b83051eda5e5c--