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 5CCA91191 for ; Fri, 5 Feb 2016 10:20:30 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3C4EA132 for ; Fri, 5 Feb 2016 10:20:29 +0000 (UTC) Received: by mail-vk0-f43.google.com with SMTP id c3so7200561vkb.3 for ; Fri, 05 Feb 2016 02:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Yx/abHP+zcPvvk1Jlt3TBMmDhQRV/D+P4oxSByELlcg=; b=PFLdhRkE65+2kp1OdqajOklxFHewbd10jm3xCWAxqy/99NsqA/qu2yCV/19RPwKC6H aakXSt4TJHblyNp63jpt4nCZtb2kb+JO/UlO57kuEckdCPBWEIXpGMvS1kH+cPNKnvFM zMH5pHxvuAR3DITvhdXxr4Sa0K7Or2+AHsLDvze7pRdVSmU+68M2rMmAK14qB5QNW1ZK +aWGBpetUSJyoU5pfKhzsCLG+2M7DwBO9Pd6ZeWL4u5tJHIDge4kmRlmUJZauO202QmA gY3b4yyMGb28V/6GLTqllRp4QEJZT8FuzVjL6RoDNPswpWkeia4hjnX2O3rE4ifpZ+V9 qOZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Yx/abHP+zcPvvk1Jlt3TBMmDhQRV/D+P4oxSByELlcg=; b=Dh3gg1FamU6xWsQkVMKqBKZNyjgUZ28F3qQ6Tr69KjdSx24/RMGF8f5sOi4nqglyrJ 9zNjwUceLqaPLbjcF0ZBBZWvG0I/rBzaHd9CC2Cw+zc4YuJN6aVcGnlZKPmXIXlVWNwz H3y4G0ljETrafowfksEwNwynBGoOhrfQYgeyqY7rdlqmYHVzKmwAaJnXdmdkvcL69QHA ZFpWrgphwEemrWJlNOMrgL1y0ZGkTOUb/WeEk4rYeyzohHAHlRPDR8gzrnNCGtwpr/Ja 9Tl7RSNEqiWiC77u5uxGxik9NPERPT2AlRauo420sOsFQrQJ3XB/ApE5uTPVyTiLJU3o k96A== X-Gm-Message-State: AG10YORWr7fdaXgqJtsTXUV2ZKJ/qLnDCr7X+qLf87AQyE4jHye8/rdLp1CxlsGN8fbgap0mdG8Lr7/dMUJgyw== MIME-Version: 1.0 X-Received: by 10.31.159.136 with SMTP id i130mr8949940vke.144.1454667628332; Fri, 05 Feb 2016 02:20:28 -0800 (PST) Received: by 10.31.141.73 with HTTP; Fri, 5 Feb 2016 02:20:28 -0800 (PST) Received: by 10.31.141.73 with HTTP; Fri, 5 Feb 2016 02:20:28 -0800 (PST) In-Reply-To: <201602041829.13459.luke@dashjr.org> References: <201602041829.13459.luke@dashjr.org> Date: Fri, 5 Feb 2016 11:20:28 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Luke-Jr Content-Type: multipart/alternative; boundary=001a1142ed9640dfdf052b0333c4 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 Dev Subject: Re: [bitcoin-dev] Hardfork bit BIP 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: Fri, 05 Feb 2016 10:20:30 -0000 --001a1142ed9640dfdf052b0333c4 Content-Type: text/plain; charset=UTF-8 On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote: > > ABSTRACT > > > > This document specifies a proposed change to the semantics of the sign > > bit of the "version" field in Bitcoin block headers, as a mechanism to > > indicate a hardfork is deployed. > > Disagree with treating the "version" field as a number, in BIP 9 or this BIP > which reinterpret it as a bit vector. I don't interpret this as "treating version bits as a number" it is just being explained which bit we're talking about. Could you propose some concrete rephrasing instead of leaving the task of somehow solving this vague and subtle concern to the author? > > FLAG BLOCK Any planned hardfork must have one and only one flag block > > which is the "point of no return". To ensure monotonicity, flag block > > should be determined by block height, or as the first block with > > GetMedianTimePast() greater than a threshold. Other mechanisms could be > > difficult for SPV nodes to follow. The height/time threshold could be a > > predetermined value or relative to other events (e.g. 10000 blocks / 100 > > days after 95% of miner support). The exact mechanism is out of the > > scope of this BIP. No matter what mechanism is used, the threshold is > > consensus critical. It must be publicly verifiable with only blockchain > > data, and preferably SPV-friendly (i.e. verifiable with block headers > > only, without downloading any transaction). > > With the current codebase, it is significantly easier to trigger on the block > timestamp rather than its height or median-time-past. Using either of the > latter would require refactoring of CBlockIndex. As a hard-fork, even if the > rules are ineffective for a few blocks following the forking point, using the > hardfork version bit in this BIP would still ensure a clean break. While I > agree that median-time-past and height are superior methods that ought to be > used for hardforks, an emergency hardfork may need to avoid them for > simplicity, and I don't think they need to be mandated as such in this BIP. I very much disagree with "significant" and in any case it depends on the hardfork: the changes required can still be quite minimal in all cases and it should never be a problem, even for emergency hardforks. In emergency, we could for example just a new global (we have many already anyway), although activeChain.tip () is already there and one can simply get the last height or median time from there. > > VERSION BITS This proposal is also compatible with the BIP9. The version > > bits mechanism could be employed to measure miner support towards a > > hardfork proposal, and to determine the height or time threshold of the > > flag block. Also, miners of the flag block may still cast votes for > > other concurrent softfork or hardfork proposals as normal. > > Rather not imply BIP 9 should be used for hardforks, or that miners have any > voice in the decision. This is already a serious misconception. This is consistent with bip99, which recommends bip9 for deploying uncontroversial hardforks. > > POINT OF NO RETURN After the flag block is generated, a miner may > > support either the original rules or the new rules, but not both. It is > > not possible for miners in one fork to attack or overtake the other fork > > without giving up the mining reward of their preferred fork. > > This is not actually desirable, and would suggest a possible reason *not* to > comply with this BIP. A legitimate hardfork would never have two continued > sets of rules for miners to choose from. Controversial hardforks (as defined bip9) always have the potential to create two chains that survive for unbounded amounts of time (maybe forever) as discussed in one of the few threads of the bitcoin discuss mailing list. Of course, BIP99 cannot say anything general about the "legitimacy" of all controversial hardforks since ASIC-reset hardforks, for example, are controversial hardforks by definition in the context of bip99 (and the definitions in bip99 seem to apply to this bip). BIP99 can only warn about the dangers and risks of controversial hardforks but at some point (let's hope never) a controversial hardfork may be required to save the system from some evil (say, evil miners blacklisting via softforking out the miners that don't blacklist or something) and that controversial hardfork would be legitimate (at least to the eyes of some). --001a1142ed9640dfdf052b0333c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 4, 2016 19:29, "Luke Dashjr via bitcoin-dev" <bitcoin-dev@lists.linuxfo= undation.org> wrote:
>
> On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote= :
> > ABSTRACT
> >
> > This document specifies a proposed change to the semantics of the= sign
> > bit of the "version" field in Bitcoin block headers, as= a mechanism to
> > indicate a hardfork is deployed.
>
> Disagree with treating the "version" field as a number, in B= IP 9 or this BIP
> which reinterpret it as a bit vector.

I don't interpret this as "treating version bits as= a number" it is just being explained which bit we're talking abou= t. Could you propose some concrete rephrasing instead of leaving the task o= f somehow solving this vague and subtle concern to the author?

> > FLAG BLOCK Any planned hardfork must have one and = only one flag block
> > which is the "point of no return". To ensure monotonici= ty, flag block
> > should be determined by block height, or as the first block with<= br> > > GetMedianTimePast() greater than a threshold. Other mechanisms co= uld be
> > difficult for SPV nodes to follow. The height/time threshold coul= d be a
> > predetermined value or relative to other events (e.g. 10000 block= s / 100
> > days after 95% of miner support). The exact mechanism is out of t= he
> > scope of this BIP. No matter what mechanism is used, the threshol= d is
> > consensus critical. It must be publicly verifiable with only bloc= kchain
> > data, and preferably SPV-friendly (i.e. verifiable with block hea= ders
> > only, without downloading any transaction).
>
> With the current codebase, it is significantly easier to trigger on th= e block
> timestamp rather than its height or median-time-past. Using either of = the
> latter would require refactoring of CBlockIndex. As a hard-fork, even = if the
> rules are ineffective for a few blocks following the forking point, us= ing the
> hardfork version bit in this BIP would still ensure a clean break. Whi= le I
> agree that median-time-past and height are superior methods that ought= to be
> used for hardforks, an emergency hardfork may need to avoid them for > simplicity, and I don't think they need to be mandated as such in = this BIP.

I very much disagree with "significant" and in any= case it depends on the hardfork: the changes required can still be quite m= inimal in all cases and it should never be a problem, even for emergency ha= rdforks. In emergency, we could for example just a new global (we have many= already anyway), although activeChain.tip () is already there and one can = simply get the last height or median time from there.

> > VERSION BITS This proposal is also compatible with= the BIP9. The version
> > bits mechanism could be employed to measure miner support towards= a
> > hardfork proposal, and to determine the height or time threshold = of the
> > flag block. Also, miners of the flag block may still cast votes f= or
> > other concurrent softfork or hardfork proposals as normal.
>
> Rather not imply BIP 9 should be used for hardforks, or that miners ha= ve any
> voice in the decision. This is already a serious misconception.

This is consistent with bip99, which recommends bip9 for dep= loying uncontroversial hardforks.

> > POINT OF NO RETURN After the flag block is generat= ed, a miner may
> > support either the original rules or the new rules, but not both.= It is
> > not possible for miners in one fork to attack or overtake the oth= er fork
> > without giving up the mining reward of their preferred fork.
>
> This is not actually desirable, and would suggest a possible reason *n= ot* to
> comply with this BIP. A legitimate hardfork would never have two conti= nued
> sets of rules for miners to choose from.

Controversial hardforks (as defined bip9) always have the po= tential to create two chains that survive for unbounded amounts of time (ma= ybe forever) as discussed in one of the few threads of the bitcoin discuss = mailing list.
Of course, BIP99 cannot say anything general about the "legitimacy&quo= t; of all controversial hardforks since ASIC-reset hardforks, for example, = are controversial hardforks by definition in the context of bip99 (and the = definitions in bip99 seem to apply to this bip). BIP99 can only warn about = the dangers and risks of controversial hardforks but at some point (let'= ;s hope never) a controversial hardfork may be required to save the system = from some evil (say, evil miners blacklisting via softforking out the miner= s that don't=C2=A0 blacklist or something) and that controversial hardf= ork would be legitimate (at least to the eyes of some).

--001a1142ed9640dfdf052b0333c4--