summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeff Garzik <jgarzik@gmail.com>2015-09-03 10:34:02 -0400
committerbitcoindev <bitcoindev@gnusha.org>2015-09-03 14:34:05 +0000
commite4d27bf260b70762b56b8a4b38cd3ac783e3503c (patch)
treec3f4bf46eaf349758d4fcadde8caae4a9d7fd147
parent4c5b052d992e675a91ee1b582936c2b5a13c5803 (diff)
downloadpi-bitcoindev-e4d27bf260b70762b56b8a4b38cd3ac783e3503c.tar.gz
pi-bitcoindev-e4d27bf260b70762b56b8a4b38cd3ac783e3503c.zip
Re: [bitcoin-dev] BIP 100 specification
-rw-r--r--66/7bccf9dd5b7ec99539a1807433ee98a140de16405
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&#39;t get the communi=
+ty&#39;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">&lt;<a href=3D=
+"mailto:btcdrak@gmail.com" target=3D"_blank">btcdrak@gmail.com</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">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>
+&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
+sts.linuxfoundation.org</a>&gt; wrote:<br>
+&gt; Some comments:<br>
+&gt;<br>
+&gt; The 75% rule is meaningless here. Since this is a pure relaxation of r=
+ules,<br>
+&gt; there is no such thing as &quot;invalid version 4 blocks&quot;<br>
+&gt;<br>
+&gt; The implication threshold is unclear. Is it 95% or 80%?<br>
+&gt;<br>
+&gt; Softfork requires a very high threshold (95%) to &quot;attack&quot; th=
+e original fork.<br>
+&gt; This makes sure that unupgraded client will only see the new fork.<br>
+&gt; In the case of hardfork, however, the new fork is unable to attack the=
+<br>
+&gt; original fork, and unupgraded client will never see the new fork. The<=
+br>
+&gt; initiation of a hardfork should be based on its acceptance by the econ=
+omic<br>
+&gt; majority, not miner support. 95% is an overkill and may probably never=
+<br>
+&gt; accomplished. I strongly prefer a 80% threshold rather than 95%.<br>
+&gt;<br>
+&gt; As I&#39;ve pointed out, using 20-percentile rather than median create=
+s an<br>
+&gt; incentive to 51% attack the uncooperative minority.<br>
+&gt; <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>
+&gt;<br>
+&gt; Having said that, I don&#39;t have a strong feeling about the use of<b=
+r>
+&gt; 20-percentile as threshold to increase the block size. That means the =
+block<br>
+&gt; size is increased only when most miners agree, which sounds ok to me.<=
+br>
+&gt;<br>
+&gt; However, using 20-percentile as threshold to DECREASE the block size c=
+ould<br>
+&gt; be very dangerous. Consider that the block size has been stable at 8MB=
+ for a<br>
+&gt; few years. Everyone are happy with that. An attacker would just need t=
+o<br>
+&gt; acquire 21% of mining power to break the status quo and send us all th=
+e way<br>
+&gt; to 1MB. The only way to stop such attempt is to 51% attack the attacke=
+r.<br>
+&gt; That&#39;d be really ugly.<br>
+&gt;<br>
+&gt; For technical and ethical reasons, I believe the thresholds for increa=
+se and<br>
+&gt; decrease must be symmetrical: increase the block size when the x-perce=
+ntile<br>
+&gt; is bigger than the current size, decrease the block size when the<br>
+&gt; (100-x)-percentile is smaller than the current size. The overall effec=
+t is:<br>
+&gt; the block size remains unchanged unless 80% of miners agree to.<br>
+&gt;<br>
+&gt; Please consider the use of &quot;hardfork bit&quot; to signify the har=
+dfork:<br>
+&gt;<br>
+&gt; <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>
+&gt;<br>
+&gt; <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>
+&gt;<br>
+&gt; Or, alternatively, please combine the hardfork with a softfork. I&#39;=
+m<br>
+&gt; rewriting the specification as follow (changes underlined):<br>
+&gt;<br>
+&gt; Replace static 1M block size hard limit with a floating limit (&quot;h=
+ardLimit&quot;).<br>
+&gt;<br>
+&gt; hardLimit floats within the range 1-32M, inclusive.<br>
+&gt;<br>
+&gt; Initial value of hardLimit is 1M, preserving current system.<br>
+&gt;<br>
+&gt; Changing hardLimit is accomplished by encoding a proposed value within=
+ a<br>
+&gt; block&#39;s coinbase scriptSig.<br>
+&gt;<br>
+&gt; Votes refer to a byte value, encoded within the pattern &quot;/BV\d+/&=
+quot; Example:<br>
+&gt; /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than =
+one<br>
+&gt; match with with pattern, the first match is counted.<br>
+&gt; Absent/invalid votes and votes below minimum cap (1M) are counted as 1=
+M<br>
+&gt; votes. Votes above the maximum cap (32M) are counted as 32M votes.<br>
+&gt; A new hardLimit is calculated at each difficult adjustment period (201=
+6<br>
+&gt; blocks), and applies to the next 2016 blocks.<br>
+&gt; Calculate hardLimit by examining the coinbase scriptSig votes of the<b=
+r>
+&gt; previous 12,000 blocks, and taking the 20th percentile and 80th percen=
+tile.<br>
+&gt; New hardLimit is the median of the followings:<br>
+&gt;<br>
+&gt; min(current hardLimit * 1.2, 20-percentile)<br>
+&gt; max(current hardLimit / 1.2, 80-percentile)<br>
+&gt; current hardLimit<br>
+&gt;<br>
+&gt; version 4 block: the coinbase of a version 4 block must match this pat=
+tern:<br>
+&gt; &quot;/BV\d+/&quot;<br>
+&gt; 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,=
+<br>
+&gt; reject invalid version 4 blocks. (testnet4: 501 of last 1000)<br>
+&gt; 80% rule (&quot;Point of no return&quot;): If 9,600 of the last 12,000=
+ blocks are<br>
+&gt; version 4 or greater, reject all version &lt;=3D 3 blocks. (testnet4: =
+750 of last<br>
+&gt; 1000)<br>
+&gt; Block version number is calculated after masking out high 16 bits (fin=
+al bit<br>
+&gt; count TBD by versionBits outcome).<br>
+&gt;<br>
+&gt; Jeff Garzik via bitcoin-dev =E6=96=BC 2015-09-02 23:33 =E5=AF=AB=E5=88=
+=B0:<br>
+&gt;&gt; BIP 100 initial public draft:<br>
+&gt;&gt; <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>
+&gt;&gt;<br>
+&gt;&gt; Emphasis on &quot;initial&quot;=C2=A0 This is a starting point for=
+ the usual open<br>
+&gt;&gt; source feedback/iteration cycle, not an endpoint that Must Be This=
+<br>
+&gt;&gt; Way.<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt;<br>
+&gt;&gt; Links:<br>
+&gt;&gt; ------<br>
+&gt;&gt; [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>
+&gt;&gt;<br>
+&gt;&gt; _______________________________________________<br>
+&gt;&gt; bitcoin-dev mailing list<br>
+&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
+ev@lists.linuxfoundation.org</a><br>
+&gt;&gt; <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>
+&gt;<br>
+&gt;<br>
+&gt; _______________________________________________<br>
+&gt; bitcoin-dev mailing list<br>
+&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
+ists.linuxfoundation.org</a><br>
+&gt; <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>
+&gt;<br>
+</div></div></blockquote></div><br></div>
+
+--089e0141aa1ab3516f051ed8ac78--
+