Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 68805119B for ; 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 ; Thu, 3 Sep 2015 14:34:03 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so22151120wic.1 for ; 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: References: Date: Thu, 3 Sep 2015 10:34:02 -0400 Message-ID: From: Jeff Garzik To: Btc Drak 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 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: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 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 > 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
A discussion of rolling out BIP 100 will not be avoided :)=

It is a hard fork; it would be silly to elide discussio= n of these key issues.

I don't get the communi= ty'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 actu= al 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@li= sts.linuxfoundation.org> wrote:
> Some comments:
>
> The 75% rule is meaningless here. Since this is a pure relaxation of r= ules,
> 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" th= e 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<= br> > initiation of a hardfork should be based on its acceptance by the econ= omic
> 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 create= s an
> incentive to 51% attack the uncooperative minority.
> https://lists.li= nuxfoundation.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.<= br> >
> However, using 20-percentile as threshold to DECREASE the block size c= ould
> 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 t= o
> acquire 21% of mining power to break the status quo and send us all th= e way
> to 1MB. The only way to stop such attempt is to 51% attack the attacke= r.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increa= se and
> decrease must be symmetrical: increase the block size when the x-perce= ntile
> is bigger than the current size, decrease the block size when the
> (100-x)-percentile is smaller than the current size. The overall effec= t is:
> the block size remains unchanged unless 80% of miners agree to.
>
> Please consider the use of "hardfork bit" to signify the har= dfork:
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_d= raft_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 ("h= ardLimit").
>
> 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+/&= quot; 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 1= M
> votes. Votes above the maximum cap (32M) are counted as 32M votes.
> A new hardLimit is calculated at each difficult adjustment period (201= 6
> 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 percen= tile.
> 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 pat= tern:
> "/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 (fin= al 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"=C2=A0 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/jgar= zik/bip100/blob/master/bip-0100.mediawiki
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>

--089e0141aa1ab3516f051ed8ac78--