Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DDA94F99 for ; 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 ; 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 ) 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 In-Reply-To: References: Message-ID: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 
Some comments:
  • 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"
  • 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 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%.
  • 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

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.

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.

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.

  • Please consider the use of "hardfork bit" to signify the hardfork:

htt= ps://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bi= t_jl2012_at_xbthk_jul_23_2015/

htt= ps://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki

  • Or, alternatively, please combine the hardfork with a softfork. I'm rew= riting the specification as follow (changes underlined):
  1. Replace static 1M block size hard limit with a floating limit ("hardLim= it").
  2. hardLimit floats within the range 1-32M, inclusive.
  3. Initial value of hardLimit is 1M, preserving current system.
  4. Changing hardLimit is accomplish= ed by encoding a proposed value within a block's coinbase scriptSig.=
    1. Votes refer to a byte value, enc= oded within the pattern "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 = byte hardLimit. If there is more than one match with with pattern, the first= match is counted.
    2. 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.
    3. A new hardLimit is calculated at= each difficult adjustment period (2016 blocks), and applies to the next 20= 16 blocks.
    4. Calculate hardLimit by examining= the coinbase scriptSig votes of the previous 12,000 blocks, and taking the = 20th percentile and 80th percentile.
    5. New = hardLimit is the median of the followings:
      1. min(c= urrent hardLimit * 1.2, 20-percentile)
      2. max(= current hardLimit / 1.2, 80-percentile)
      3. curr= ent hardLimit
  5. version 4 block: the coinbase of = a version 4 block must match this pattern: "/BV\d+/"
  6. 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater, reject invalid versio= n 4 blocks. (testnet4: 501 of last 1000)
  7. 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)<= /li>
  8. Block version number is calculat= ed after masking out high 16 bits (final bit count TBD by versionBits outco= me).
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
--=_f22692d174c8b182acef4bf5ba1b6ed0--