From mboxrd@z Thu Jan 1 00:00:00 1970 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 'M' suffix and removed 'V' 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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target= =3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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'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 "/BVd*/" instead of "/BVd+/"<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 "/BV(\d+[KM]?)?/"<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> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla= nk">bitcoin-dev@lists.linuxfoundation.org</a>> 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's coinbase scriptSig.<br> <br></span> * Votes refer to a byte value, encoded within the pattern "/BVd+/"= ;<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'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--