diff options
| author | jl2012 <jl2012@xbt.hk> | 2015-09-03 03:57:09 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-09-03 07:57:11 +0000 |
| commit | 537d1a77604c7b0992a270f1029aaa4e21e1373d (patch) | |
| tree | 615c03ec4ae8dfcbbab65f69644559df9f0aa30d | |
| parent | a4f0ed78cc10a9538fa2ba21595455b19d09a61f (diff) | |
| download | pi-bitcoindev-537d1a77604c7b0992a270f1029aaa4e21e1373d.tar.gz pi-bitcoindev-537d1a77604c7b0992a270f1029aaa4e21e1373d.zip | |
Re: [bitcoin-dev] BIP 100 specification
| -rw-r--r-- | ed/c202c2c1b8800dd12f3cfe7f6947063a77720f | 319 |
1 files changed, 319 insertions, 0 deletions
diff --git a/ed/c202c2c1b8800dd12f3cfe7f6947063a77720f b/ed/c202c2c1b8800dd12f3cfe7f6947063a77720f new file mode 100644 index 000000000..f661ba5de --- /dev/null +++ b/ed/c202c2c1b8800dd12f3cfe7f6947063a77720f @@ -0,0 +1,319 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id DDA94F99 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 3 Sep 2015 07:57:11 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1ACAE149 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 3 Sep 2015 07:57:10 +0000 (UTC) +Received: from localhost ([::1]:40246 helo=server47.web-hosting.com) + by server47.web-hosting.com with esmtpa (Exim 4.85) + (envelope-from <jl2012@xbt.hk>) + id 1ZXPOP-00257P-RY; Thu, 03 Sep 2015 03:57:09 -0400 +MIME-Version: 1.0 +Content-Type: multipart/alternative; + boundary="=_f22692d174c8b182acef4bf5ba1b6ed0" +Date: Thu, 03 Sep 2015 03:57:09 -0400 +From: jl2012@xbt.hk +To: Jeff Garzik <jgarzik@gmail.com> +In-Reply-To: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com> +References: <CADm_WcZyK6LUcuKqSEuR-q0hTZOC3EdJsqY1HrS_ow0knDY=7A@mail.gmail.com> +Message-ID: <e54e93e519d776262f9c0f4ae23f54fb@xbt.hk> +X-Sender: jl2012@xbt.hk +User-Agent: Roundcube Webmail/1.0.5 +X-AntiAbuse: This header was added to track abuse, + please include it with any abuse report +X-AntiAbuse: Primary Hostname - server47.web-hosting.com +X-AntiAbuse: Original Domain - lists.linuxfoundation.org +X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] +X-AntiAbuse: Sender Address Domain - xbt.hk +X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: + jl2012@xbt.hk +X-Source: +X-Source-Args: +X-Source-Dir: +X-From-Rewrite: unmodified, already matched +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 07:57:12 -0000 + +--=_f22692d174c8b182acef4bf5ba1b6ed0 +Content-Transfer-Encoding: 8bit +Content-Type: text/plain; charset=UTF-8 + + + +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/010690.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 increase +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_hardfork_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 "/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. + * 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: "/BVd+/" + * 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 <= 3 blocks. (testnet4: 750 +of last 1000) + * Block version number is calculated after masking out high 16 bits +(final bit count TBD by versionBits outcome). + +Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到: +> 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 + + +--=_f22692d174c8b182acef4bf5ba1b6ed0 +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; charset=UTF-8 + +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"> +<html><body style=3D'font-size: 10pt; font-family: Verdana,Geneva,sans-seri= +f'> +<pre>Some comments:</pre> +<ul> +<li>The 75% rule is meaningless here. Since this is a pure relaxation of ru= +les, there is no such thing as "invalid version 4 blocks"</li> +</ul> +<ul> +<li> +<pre>The implication threshold is unclear. Is it 95% or 80%?</pre> +</li> +<ul> +<li>Softfork requires a very high threshold (95%) to "attack" the original = +fork. This makes sure that unupgraded client will only see the new fork.</l= +i> +<li>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 initi= +ation of a hardfork should be based on its acceptance by the economic major= +ity, not miner support. 95% is an overkill and may probably never accomplis= +hed. I strongly prefer a 80% threshold rather than 95%.</li> +</ul> +</ul> +<ul> +<li>As I've pointed out, using 20-percentile rather than median creates an = +incentive to 51% attack the uncooperative minority. https://lists.linuxfoun= +dation.org/pipermail/bitcoin-dev/2015-August/010690.html</li> +</ul> +<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">Hav= +ing 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 incr= +eased only when most miners agree, which sounds ok to me.</span></p> +<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;"></s= +pan>However, using 20-percentile as threshold to DECREASE the block size co= +uld 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= +=2E That'd be really ugly.</p> +<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">For= + technical and ethical reasons, I believe the thresholds for increase and d= +ecrease 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)-p= +ercentile is smaller than the current size. The overall effect is: the bloc= +k size remains unchanged unless 80% of miners agree to.</span></p> +<ul> +<li>Please consider the use of "hardfork bit" to signify the hardfork:</li> +</ul> +<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">htt= +ps://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bi= +t_jl2012_at_xbthk_jul_23_2015/</span></p> +<p style=3D"padding-left: 30px;"><span style=3D"white-space: pre-wrap;">htt= +ps://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki</span></p> +<ul> +<li>Or, alternatively, please combine the hardfork with a softfork. I'm rew= +riting the specification as follow (changes underlined):</li> +</ul> +<ol> +<li>Replace static 1M block size hard limit with a floating limit ("hardLim= +it").</li> +<li> +<pre>hardLimit floats within the range 1-32M, inclusive.</pre> +</li> +<li> +<pre>Initial value of hardLimit is 1M, preserving current system.</pre> +</li> +<li><span style=3D"white-space: pre-wrap;">Changing hardLimit is accomplish= +ed by encoding a proposed value within a block's coinbase scriptSig.</span>= +</li> +<ol> +<li><span style=3D"white-space: pre-wrap;">Votes refer to a byte value, enc= +oded within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 = +byte hardLimit. </span><span style=3D"white-space: pre-wrap; text-decoratio= +n: underline;">If there is more than one match with with pattern, the first= + match is counted.</span></li> +<li><span style=3D"white-space: pre-wrap;">Absent/invalid votes and votes b= +elow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap = +(32M) are counted as 32M votes.</span></li> +<li><span style=3D"white-space: pre-wrap;">A new hardLimit is calculated at= + each difficult adjustment period (2016 blocks), and applies to the next 20= +16 blocks.</span></li> +<li><span style=3D"white-space: pre-wrap;">Calculate hardLimit by examining= + the coinbase scriptSig votes of the previous 12,000 blocks, </span><span s= +tyle=3D"white-space: pre-wrap; text-decoration: underline;">and taking the = +20th percentile and 80th percentile.</span></li> +<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">New = +hardLimit is the median of the followings:</span></li> +<ol> +<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">m</s= +pan><span style=3D"text-decoration: underline; white-space: pre-wrap;">in(c= +urrent hardLimit * 1.2, 20-percentile)</span></li> +<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">max(= +current hardLimit / 1.2, 80-percentile)</span></li> +<li><span style=3D"text-decoration: underline; white-space: pre-wrap;">curr= +ent hardLimit</span></li> +</ol></ol> +<li><span style=3D"white-space: pre-wrap;"></span><span style=3D"white-spac= +e: pre-wrap; text-decoration: underline;">version 4 block: the coinbase of = +a version 4 block must match this pattern: "/BV\d+/"</span></li> +<li><span style=3D"white-space: pre-wrap;"></span><span style=3D"white-spac= +e: pre-wrap; text-decoration: underline;">70%</span><span style=3D"white-sp= +ace: pre-wrap;"> rule:</span><span style=3D"white-space: pre-wrap; text-dec= +oration: underline;"> If 8,400</span><span style=3D"white-space: pre-wrap;"= +> of the last 12,000 blocks are version 4 or greater, reject invalid versio= +n 4 blocks. (testnet4: 501 of last 1000)</span></li> +<li><span style=3D"white-space: pre-wrap;"></span><span style=3D"white-spac= +e: pre-wrap; text-decoration: underline;">80%</span><span style=3D"white-sp= +ace: pre-wrap;"> rule ("Point of no return"): If </span><span style=3D"whit= +e-space: pre-wrap; text-decoration: underline;">9,600</span><span style=3D"= +white-space: pre-wrap;"> of the last 12,000 blocks are version 4 or greater= +, reject all version <=3D 3 blocks. (testnet4: 750 of last 1000)</span><= +/li> +<li><span style=3D"white-space: pre-wrap;">Block version number is calculat= +ed after masking out high 16 bits (final bit count TBD by versionBits outco= +me).</span></li> +</ol> +<pre> +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] +>=20 +> Emphasis on "initial" This is a starting point for the usual open +> source feedback/iteration cycle, not an endpoint that Must Be This +> Way. +>=20 +>=20 +>=20 +> Links: +> ------ +> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki +>=20 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +</pre> +</body></html> + +--=_f22692d174c8b182acef4bf5ba1b6ed0-- + + |