From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1169C1119 for ; Thu, 3 Sep 2015 14:35:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8BB9210B for ; Thu, 3 Sep 2015 14:35:57 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so10544742wic.1 for ; Thu, 03 Sep 2015 07:35:56 -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=+0M7vWOVxf6EH0RdLZ1Yse0mvkF+odoV9xfQ9OicJ+8=; b=xmTNjRjr/eWpM0sqYX8+nDbergj37zIoStcmdKjTxheXsdp0FYEjm/WbTRxm8FATie aytkUrovQXx0Ilw8gMEtfX1owS1Ft6MLSaCmExbM2S6yGZF6LS6Nm/gALZcLXDHDVMtN mVBFEJsNI+zdbODGaH4K4jhYETGEdZ3v4puLqzpnA20FM9rxa3N/EaqgGvMp6RTiA2Hj SikZuXQzdUx1UqHu3DccamGGlvWpJX8B+yl/uiGAvSM+NxTpe2oFfiakJB5Iewn96Una WwdEkUOZwlX001t9ij+KApR6BiHqpjoRNfERAx3Aw2qlde5nPpsXAg/1cswT6dKA2XBq gL5Q== MIME-Version: 1.0 X-Received: by 10.195.18.5 with SMTP id gi5mr54820904wjd.0.1441290956202; Thu, 03 Sep 2015 07:35:56 -0700 (PDT) Received: by 10.28.15.11 with HTTP; Thu, 3 Sep 2015 07:35:56 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Sep 2015 10:35:56 -0400 Message-ID: From: Jeff Garzik To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=001a11c282147667dc051ed8b383 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 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 14:35:59 -0000 --001a11c282147667dc051ed8b383 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks - several good suggestions, including some in common. Will comment & revise today. Currently in "collecting" mode, to avoid duplicative comments in multiple locales. On Thu, Sep 3, 2015 at 3:57 AM, 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 acceptanc= e by the > economic majority, not miner support. 95% is an overkill and may pr= obably > never accomplished. I strongly prefer a 80% threshold rather than 9= 5%. > > > - 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/01= 0690.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 blo= ck > size is increased only when most miners agree, which sounds ok to me. > > However, using 20-percentile as threshold to DECREASE the block size coul= d > be very dangerous. Consider that the block size has been stable at 8MB fo= r > 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 w= ay > 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 whe= n > the (100-x)-percentile is smaller than the current size. The overall effe= ct > 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): > > > 1. Replace static 1M block size hard limit with a floating limit > ("hardLimit"). > 2. > > hardLimit floats within the range 1-32M, inclusive. > > 3. > > Initial value of hardLimit is 1M, preserving current system. > > 4. Changing hardLimit is accomplished by encoding a proposed value > within a block's coinbase scriptSig. > 1. 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 one match with with pattern, the first match is = counted. > 2. 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. > 3. A new hardLimit is calculated at each difficult adjustment > period (2016 blocks), and applies to the next 2016 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(current hardLimit * 1.2, 20-percentile) > 2. max(current hardLimit / 1.2, 80-percentile) > 3. current 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 version 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) > 8. Block version number is calculated after masking out high 16 bits > (final 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 > > --001a11c282147667dc051ed8b383 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks - several good suggestions, including some in commo= n.=C2=A0 Will comment & revise today.

Currently in &= quot;collecting" mode, to avoid duplicative comments in multiple local= es.


On Thu, Sep 3, 2015 at 3:57 AM, <jl2012@xbt.hk> wrote:
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 ne= w 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%.

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 incr= eased 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 a= cquire 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. Th= at'd be really ugly.

For tec= hnical and ethical reasons, I believe the thresholds for increase and decre= ase must be symmetrical: increase the block size when the x-percentile is b= igger than the current size, decrease the block size when the (100-x)-perce= ntile is smaller than the current size. The overall effect is: the block si= ze remains unchanged unless 80% of miners agree to.

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

https://www.reddit= .com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbt= hk_jul_23_2015/

https://github.com/jl2012/bips/blob/master/hardforkbit.mediawi= ki

  • Or, alternatively, please combine the hardfork with a softfork. I'm= rewriting the specification as follow (changes underlined):
  1. Replace static 1M block size hard limit with a floating limit ("ha= rdLimit").
  2. hardLimit floats within the range 1-32M, inclusive.
  3. Initial value of hardLimit is 1M, preserving current system.
  4. Changing hardLimit is accomplished= by encoding a proposed value within a block's coinbase scriptSig.
    1. Votes refer to a byte value, encod= ed 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 f= irst match is counted.
    2. Absent/invalid votes and votes bel= ow minimum cap (1M) are counted as 1M votes. Votes above the maximum cap (3= 2M) are counted as 32M votes.
    3. A new hardLimit is calculated at e= ach difficult adjustment period (2016 blocks), and applies to the next 2016= blocks.
    4. Calculate hardLimit by examining t= he coinbase scriptSig votes of the previous 12,000 blocks, and taking the 20th p= ercentile and 80th percentile.
    5. New hard= Limit is the median of the followings:
      1. m= in(current h= ardLimit * 1.2, 20-percentile)
      2. max(curr= ent hardLimit / 1.2, 80-percentile)
      3. current = hardLimit
  5. version 4 block: the coinbase of a vers= ion 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 version 4 blocks. (t= estnet4: 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, re= ject all version <=3D 3 blocks. (testnet4: 750 of last 1000)
  8. Block version number is calculated= after masking out high 16 bits (final 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]
>=20
> Emphasis on "initial"  This is a starting point for the usua=
l 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/b=
itcoin-dev

--001a11c282147667dc051ed8b383--