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 106F1118B for ; Thu, 4 Feb 2016 18:29:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 85D992F for ; Thu, 4 Feb 2016 18:29:28 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 7459038A99F7; Thu, 4 Feb 2016 18:29:14 +0000 (UTC) X-Hashcash: 1:25:160204:bitcoin-dev@lists.linuxfoundation.org::fRI98Hzs9cqsL3vn:=dc5 X-Hashcash: 1:25:160204:jl2012@xbt.hk::CMobuJYVDpTy1enu:ajFOL From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, jl2012 Date: Thu, 4 Feb 2016 18:29:11 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201602041829.13459.luke@dashjr.org> X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_SBL, RP_MATCHES_RCVD autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Thu, 04 Feb 2016 18:29:29 -0000 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. > Among the 640 bits in the block header, this is the only one which is > fixed and serves no purpose, ... Minor nit (not relevant to actual proposal): This is not true. There are over 32 other bits (part of the "previous-block" field) which also serve no purpose. > 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. > Although a hardfork is officially deployed when flag block is generated, ... I would avoid implying the hardfork can be "officially deployed" without actual adoption. > AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is > found on the network, full nodes and SPV nodes should alert their users > and/or stop accepting/sending transactions. It should be noted that the > warning system could become a denial-of-service vector if the attacker > is willing to give up the block reward. Therefore, the warning may be > issued only if a few blocks are built on top of the flag block in a > reasonable time frame. This will in turn increase the risk in case of a > real planned hardfork so it is up to the wallet programmers to decide > the optimal strategy. Human warning system (e.g. the emergency alert > system in Bitcoin Core) could fill the gap. This seems vulnerable to DoS attacks by rejected hardforks. > 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. > 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. Luke