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 6BA4E902 for ; Thu, 1 Dec 2016 20:44:11 +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 D2E0214C for ; Thu, 1 Dec 2016 20:44:10 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id E868338AB88B; Thu, 1 Dec 2016 20:44:08 +0000 (UTC) X-Hashcash: 1:25:161201:bitcoin-dev@lists.linuxfoundation.org::YarU7y2ghwZM18eq:cKXt X-Hashcash: 1:25:161201:jl2012@xbt.hk::DcJ=TxRcuz5TgEj1:dVUC From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Johnson Lau Date: Thu, 1 Dec 2016 20:44:06 +0000 User-Agent: KMail/1.13.7 (Linux/4.4.31-gentoo; KDE/4.14.24; x86_64; ; ) References: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk> In-Reply-To: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk> 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="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201612012044.07574.luke@dashjr.org> X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] New BIP: Hardfork warning system X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 20:44:11 -0000 On Thursday, December 01, 2016 5:20:31 PM Johnson Lau via bitcoin-dev wrote: > Any bitcoin implementation (full nodes and light nodes) supporting this > softfork should also implement a hardfork warning system described below. I think this "should" needs to be a "must" be make this useful. > Hardfork with unknown rules > If a generalized block header chain with non-trivial total proof-of-work is > emerging, and is not considered as a valid blockchain, a hardfork with > unknown rules may be happening. > > A wallet implementation should issue a warning to its users and stop > processing incoming and outgoing transactions, until further instructions > are given. It should not attempt to conduct transactions on or otherwise > interpreting any block data of the hardfork with unknown rules. This seems too unclear. Specifically, if an invalid chain with *equivalent or better* work than the best valid chain exists, nodes ought to treat all blocks following the common chain (between the better-invalid and best-valid chains) as suspect. So if we have two chains: A->B->C->D (valid) A->B->X->Y (invalid) The node should consider block B as the tip until the valid chain becomes and stays longer than the invalid one. > A mining implementation should issue a warning to its operator. Until > further instructions are given, it may either stop mining, or ignore the > hardfork with unknown rules. It should not attempt to confirm a > generalized block header with unknown rules. I think we need to decide more specifically which behaviour is sane here. > Hardfork warning system in light nodes > > Light node (usually wallet implementations) is any bitcoin protocol > implementations that intentionally not fully enforcing the network rules. > As an important part of the hardfork warning system, a light node should > observe the hardfork notification bits in block header, along with any > other rules it opts to validate. If any of the hardfork notification bits > is set, it should issue a warning to its users and stop processing > incoming and outgoing transactions, until further instructions are given. > It should not attempt to conduct transactions on or otherwise interpreting > any block data of the hardfork blockchain, even if it might be able to > decode the block data. Light nodes should probably not be specified here differently than full nodes. If they detect an invalid block through *any* means, they should react the same as a full node would. > Redefining the Merkle root hash field and changing block content validation > rules The 32-byte Merkle root hash could be redefined, for example, with a > different hashing algorithm. Any block resources limitation and > transaction validation rules may also be changed. All such hardforks would > be detected by the warning system. Note, some changes may be needed to current nodes for this to work. I think at this time this would cause a "deserialisation" error, and not accept NOR reject the block... > Introducing secondary proof-of-work > Introducing secondary proof-of-work (with non-SHA256 algorithm or fixing > the block withholding attack against mining pools) may be detectable, as > long as the generalized block header format is preserved. Not necessarily. A secondary PoW might drastically change the measurement of work. Fixing block withholding may result in block hashes that meet a preimage rather than bits directly. I think it may be important to fix the latter problem for this BIP. > Accidental hardfork > An accidental hardfork may be detectable, if the generalized block headers > in both forks are valid but no hardfork notification bit is set. Probably best to not call this a hardfork, since it is a break without consensus. Luke