diff options
author | Jeff Garzik <jgarzik@gmail.com> | 2015-09-03 10:34:02 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-03 14:34:05 +0000 |
commit | e4d27bf260b70762b56b8a4b38cd3ac783e3503c (patch) | |
tree | c3f4bf46eaf349758d4fcadde8caae4a9d7fd147 | |
parent | 4c5b052d992e675a91ee1b582936c2b5a13c5803 (diff) | |
download | pi-bitcoindev-e4d27bf260b70762b56b8a4b38cd3ac783e3503c.tar.gz pi-bitcoindev-e4d27bf260b70762b56b8a4b38cd3ac783e3503c.zip |
Re: [bitcoin-dev] BIP 100 specification
-rw-r--r-- | 66/7bccf9dd5b7ec99539a1807433ee98a140de16 | 405 |
1 files changed, 405 insertions, 0 deletions
diff --git a/66/7bccf9dd5b7ec99539a1807433ee98a140de16 b/66/7bccf9dd5b7ec99539a1807433ee98a140de16 new file mode 100644 index 000000000..eb538f99c --- /dev/null +++ b/66/7bccf9dd5b7ec99539a1807433ee98a140de16 @@ -0,0 +1,405 @@ +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 68805119B + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 3 Sep 2015 14:34:05 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com + [209.85.212.177]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EF86410B + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 3 Sep 2015 14:34:03 +0000 (UTC) +Received: by wicfx3 with SMTP id fx3so22151120wic.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 03 Sep 2015 07:34:02 -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=wEc2dgx51YFCkI8lyqVXHHQonWQkv3Y82rDo/INu758=; + b=IPBMBYGLzJCHSDx3BTWWc1SVjKczJDfvKbqlo9kYL+VXcToI769m7esQE5YLZAm7gO + 9DDK9GUiAmId8gk4PBXSYSOcpjANR0WykiZACwgGxVLEHpWq9MLplftjUz1tPYiiWsJu + z/6p4NwpVRUnZONb39oUM2KWstn+NnOGrJV6SQyBa++tINdMiFfTyo0myJHSQjjcSKHP + mciU+leLGkoI1khRECk++z7WTffRPhJiQiC1vqxtEwil33h4LvGUo8hgTNlZYBvbhtha + rPJIXCUe0rhhj2+I7YnZrwTmFPi3UrpyMp0Irv786FX8B6Wg+kteLGbXVcy0CtI4QQgc + VSJg== +MIME-Version: 1.0 +X-Received: by 10.194.238.39 with SMTP id vh7mr50047597wjc.109.1441290842753; + Thu, 03 Sep 2015 07:34:02 -0700 (PDT) +Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:34:02 -0700 (PDT) +In-Reply-To: <CADJgMzuWNNvMf6f9N0h0swAUATyAm4Y9Qu+ya33cEA1WB++sRg@mail.gmail.com> +References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com> + <e54e93e519d776262f9c0f4ae23f54fb@xbt.hk> + <CADJgMzuWNNvMf6f9N0h0swAUATyAm4Y9Qu+ya33cEA1WB++sRg@mail.gmail.com> +Date: Thu, 3 Sep 2015 10:34:02 -0400 +Message-ID: <CADm_WcbVRQMFHU0pS7hi99=Ey3Pu3t6pViaPG-KpHF40w69N6A@mail.gmail.com> +From: Jeff Garzik <jgarzik@gmail.com> +To: Btc Drak <btcdrak@gmail.com> +Content-Type: multipart/alternative; boundary=089e0141aa1ab3516f051ed8ac78 +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 14:34:05 -0000 + +--089e0141aa1ab3516f051ed8ac78 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +A discussion of rolling out BIP 100 will not be avoided :) + +It is a hard fork; it would be silly to elide discussion of these key +issues. + +I don't get the community's recent interest in avoiding certain topics. + + + +On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak@gmail.com> wrote: + +> We should avoid discussing actual hard fork/softfork deployment +> methodologies when discussing blocksize proposals because deployment +> is a separate issue. As a recent case in point, look at how BIP65 +> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy. +> That lead to a focused discussion of the functionality and relatively +> quick inclusion. +> +> Deployment really is a separate issue than the mechanics of how BIP100 +> will function after activation. +> +> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev +> <bitcoin-dev@lists.linuxfoundation.org> wrote: +> > Some comments: +> > +> > The 75% rule is meaningless here. Since this is a pure relaxation of +> rules, +> > there is no such thing as "invalid version 4 blocks" +> > +> > The implication threshold is unclear. Is it 95% or 80%? +> > +> > Softfork requires a very high threshold (95%) to "attack" the original +> fork. +> > This makes sure that unupgraded client will only see the new fork. +> > In the case of hardfork, however, the new fork is unable to attack the +> > original fork, and unupgraded client will never see the new fork. The +> > initiation of a hardfork should be based on its acceptance by the +> economic +> > majority, not miner support. 95% is an overkill and may probably never +> > accomplished. I strongly prefer a 80% threshold rather than 95%. +> > +> > As I've pointed out, using 20-percentile rather than median creates an +> > incentive to 51% attack the uncooperative minority. +> > +> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/01069= +0.html +> > +> > Having said that, I don't have a strong feeling about the use of +> > 20-percentile as threshold to increase the block size. That means the +> block +> > size is increased only when most miners agree, which sounds ok to me. +> > +> > However, using 20-percentile as threshold to DECREASE the block size +> could +> > be very dangerous. Consider that the block size has been stable at 8MB +> for a +> > few years. Everyone are happy with that. An attacker would just need to +> > acquire 21% of mining power to break the status quo and send us all the +> way +> > to 1MB. The only way to stop such attempt is to 51% attack the attacker= +. +> > That'd be really ugly. +> > +> > For technical and ethical reasons, I believe the thresholds for increas= +e +> and +> > decrease must be symmetrical: increase the block size when the +> x-percentile +> > is bigger than the current size, decrease the block size when the +> > (100-x)-percentile is smaller than the current size. The overall effect +> is: +> > the block size remains unchanged unless 80% of miners agree to. +> > +> > Please consider the use of "hardfork bit" to signify the hardfork: +> > +> > +> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfo= +rk_bit_jl2012_at_xbthk_jul_23_2015/ +> > +> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki +> > +> > Or, alternatively, please combine the hardfork with a softfork. I'm +> > rewriting the specification as follow (changes underlined): +> > +> > Replace static 1M block size hard limit with a floating limit +> ("hardLimit"). +> > +> > hardLimit floats within the range 1-32M, inclusive. +> > +> > Initial value of hardLimit is 1M, preserving current system. +> > +> > 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 "/BV\d+/" +> Example: +> > /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than o= +ne +> > match with with pattern, the first match is counted. +> > 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. +> > A new hardLimit is calculated at each difficult adjustment period (2016 +> > blocks), and applies to the next 2016 blocks. +> > Calculate hardLimit by examining the coinbase scriptSig votes of the +> > previous 12,000 blocks, and taking the 20th percentile and 80th +> percentile. +> > New hardLimit is the median of the followings: +> > +> > min(current hardLimit * 1.2, 20-percentile) +> > max(current hardLimit / 1.2, 80-percentile) +> > current hardLimit +> > +> > version 4 block: the coinbase of a version 4 block must match this +> pattern: +> > "/BV\d+/" +> > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater, +> > reject invalid version 4 blocks. (testnet4: 501 of last 1000) +> > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are +> > version 4 or greater, reject all version <=3D 3 blocks. (testnet4: 750 = +of +> last +> > 1000) +> > Block version number is calculated after masking out high 16 bits (fina= +l +> bit +> > count TBD by versionBits outcome). +> > +> > Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88= +=B0: +> >> BIP 100 initial public draft: +> >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1] +> >> +> >> Emphasis on "initial" This is a starting point for the usual open +> >> source feedback/iteration cycle, not an endpoint that Must Be This +> >> Way. +> >> +> >> +> >> +> >> Links: +> >> ------ +> >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki +> >> +> >> _______________________________________________ +> >> 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 +> > +> + +--089e0141aa1ab3516f051ed8ac78 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">A discussion of rolling out BIP 100 will not be avoided :)= +<div><br></div><div>It is a hard fork; it would be silly to elide discussio= +n of these key issues.</div><div><br></div><div>I don't get the communi= +ty's recent interest in avoiding certain topics.</div><div><br></div><d= +iv><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote= +">On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <span dir=3D"ltr"><<a href=3D= +"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.com</a>></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">We should avoid discussing actu= +al hard fork/softfork deployment<br> +methodologies when discussing blocksize proposals because deployment<br> +is a separate issue. As a recent case in point, look at how BIP65<br> +(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.<br> +That lead to a focused discussion of the functionality and relatively<br> +quick inclusion.<br> +<br> +Deployment really is a separate issue than the mechanics of how BIP100<br> +will function after activation.<br> +<div class=3D"HOEnZb"><div class=3D"h5"><br> +On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev<br> +<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li= +sts.linuxfoundation.org</a>> wrote:<br> +> Some comments:<br> +><br> +> The 75% rule is meaningless here. Since this is a pure relaxation of r= +ules,<br> +> there is no such thing as "invalid version 4 blocks"<br> +><br> +> The implication threshold is unclear. Is it 95% or 80%?<br> +><br> +> Softfork requires a very high threshold (95%) to "attack" th= +e original fork.<br> +> This makes sure that unupgraded client will only see the new fork.<br> +> In the case of hardfork, however, the new fork is unable to attack the= +<br> +> original fork, and unupgraded client will never see the new fork. The<= +br> +> initiation of a hardfork should be based on its acceptance by the econ= +omic<br> +> majority, not miner support. 95% is an overkill and may probably never= +<br> +> accomplished. I strongly prefer a 80% threshold rather than 95%.<br> +><br> +> As I've pointed out, using 20-percentile rather than median create= +s an<br> +> incentive to 51% attack the uncooperative minority.<br> +> <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201= +5-August/010690.html" rel=3D"noreferrer" target=3D"_blank">https://lists.li= +nuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html</a><br> +><br> +> Having said that, I don't have a strong feeling about the use of<b= +r> +> 20-percentile as threshold to increase the block size. That means the = +block<br> +> size is increased only when most miners agree, which sounds ok to me.<= +br> +><br> +> However, using 20-percentile as threshold to DECREASE the block size c= +ould<br> +> be very dangerous. Consider that the block size has been stable at 8MB= + for a<br> +> few years. Everyone are happy with that. An attacker would just need t= +o<br> +> acquire 21% of mining power to break the status quo and send us all th= +e way<br> +> to 1MB. The only way to stop such attempt is to 51% attack the attacke= +r.<br> +> That'd be really ugly.<br> +><br> +> For technical and ethical reasons, I believe the thresholds for increa= +se and<br> +> decrease must be symmetrical: increase the block size when the x-perce= +ntile<br> +> is bigger than the current size, decrease the block size when the<br> +> (100-x)-percentile is smaller than the current size. The overall effec= +t is:<br> +> the block size remains unchanged unless 80% of miners agree to.<br> +><br> +> Please consider the use of "hardfork bit" to signify the har= +dfork:<br> +><br> +> <a href=3D"https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bi= +p_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/" rel=3D"noreferrer" targe= +t=3D"_blank">https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_d= +raft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/</a><br> +><br> +> <a href=3D"https://github.com/jl2012/bips/blob/master/hardforkbit.medi= +awiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jl2012/bips/= +blob/master/hardforkbit.mediawiki</a><br> +><br> +> Or, alternatively, please combine the hardfork with a softfork. I'= +m<br> +> rewriting the specification as follow (changes underlined):<br> +><br> +> Replace static 1M block size hard limit with a floating limit ("h= +ardLimit").<br> +><br> +> hardLimit floats within the range 1-32M, inclusive.<br> +><br> +> Initial value of hardLimit is 1M, preserving current system.<br> +><br> +> Changing hardLimit is accomplished by encoding a proposed value within= + a<br> +> block's coinbase scriptSig.<br> +><br> +> Votes refer to a byte value, encoded within the pattern "/BV\d+/&= +quot; Example:<br> +> /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than = +one<br> +> match with with pattern, the first match is counted.<br> +> Absent/invalid votes and votes below minimum cap (1M) are counted as 1= +M<br> +> votes. Votes above the maximum cap (32M) are counted as 32M votes.<br> +> A new hardLimit is calculated at each difficult adjustment period (201= +6<br> +> blocks), and applies to the next 2016 blocks.<br> +> Calculate hardLimit by examining the coinbase scriptSig votes of the<b= +r> +> previous 12,000 blocks, and taking the 20th percentile and 80th percen= +tile.<br> +> New hardLimit is the median of the followings:<br> +><br> +> min(current hardLimit * 1.2, 20-percentile)<br> +> max(current hardLimit / 1.2, 80-percentile)<br> +> current hardLimit<br> +><br> +> version 4 block: the coinbase of a version 4 block must match this pat= +tern:<br> +> "/BV\d+/"<br> +> 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,= +<br> +> reject invalid version 4 blocks. (testnet4: 501 of last 1000)<br> +> 80% rule ("Point of no return"): If 9,600 of the last 12,000= + blocks are<br> +> version 4 or greater, reject all version <=3D 3 blocks. (testnet4: = +750 of last<br> +> 1000)<br> +> Block version number is calculated after masking out high 16 bits (fin= +al bit<br> +> count TBD by versionBits outcome).<br> +><br> +> Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88= +=B0:<br> +>> BIP 100 initial public draft:<br> +>> <a href=3D"https://github.com/jgarzik/bip100/blob/master/bip-0100.= +mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jgarzik/= +bip100/blob/master/bip-0100.mediawiki</a> [1]<br> +>><br> +>> Emphasis on "initial"=C2=A0 This is a starting point for= + the usual open<br> +>> source feedback/iteration cycle, not an endpoint that Must Be This= +<br> +>> Way.<br> +>><br> +>><br> +>><br> +>> Links:<br> +>> ------<br> +>> [1] <a href=3D"https://github.com/jgarzik/bip100/blob/master/bip-0= +100.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/jgar= +zik/bip100/blob/master/bip-0100.mediawiki</a><br> +>><br> +>> _______________________________________________<br> +>> bitcoin-dev mailing list<br> +>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= +ev@lists.linuxfoundation.org</a><br> +>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc= +oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation= +.org/mailman/listinfo/bitcoin-dev</a><br> +><br> +><br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= +ists.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= +/mailman/listinfo/bitcoin-dev</a><br> +><br> +</div></div></blockquote></div><br></div> + +--089e0141aa1ab3516f051ed8ac78-- + |