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 54D92B5E for ; Thu, 1 Dec 2016 18:52:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D086D4 for ; Thu, 1 Dec 2016 18:52:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx05.mykolab.com (mx05.mykolab.com [10.20.7.161]) by mx-out01.mykolab.com (Postfix) with ESMTPS id 848BA61CF5 for ; Thu, 1 Dec 2016 19:51:58 +0100 (CET) From: Tom Zander To: bitcoin-dev@lists.linuxfoundation.org Date: Thu, 01 Dec 2016 19:51:56 +0100 Message-ID: <3691646.EHKJshi5lM@strawberry> In-Reply-To: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk> References: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 01 Dec 2016 18:52:58 +0000 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 18:52:04 -0000 I am failing to see how you actually will detect a hard fork with this=20 system. Maybe its because of this sentence not being very clear to me; =C2=ABIf a generalized block header chain with non-trivial total proof-of-= work is emerging=C2=BB Also, can you explain what you are actually trying to accomplish? I want to point out that the following part from your motivation is=20 incorrect. A full node would reject a hard forked chain (by definition),=20 there is no risk of them transacting on it. =C2=ABWhen such features are implemented with a hardfork, existing full nod= e=20 implementations would consider such blocks as invalid, and may even ban a=20 peer for relaying such blocks. They are effectively blind to such hardfork= =20 rule changes, leaving users to unknowingly transact on a system with=20 potentially different token value. =C2=BB On Friday, 2 December 2016 01:20:31 CET Johnson Lau via bitcoin-dev wrote: > This BIP defines a change in consensus rules regarding to block nVersion, > and define a concept of generalized block header to implement a hardfork > warning system for full nodes and light nodes. >=20 > For better formatting, visit github > https://github.com/jl2012/bips/blob/hfwarning/bip-hfwarning.mediawiki >=20 >=20 >=20 > BIP: ? > Title: Hardfork warning system > Author: Johnson Lau > Status: Draft > Type: Standard > Created: 2016-12-01 >=20 > Abstract >=20 > This BIP defines a change in consensus rules regarding to block nVersion, > and define a concept of generalized block header to implement a hardfork > warning system for full nodes and light nodes. >=20 > Motivation >=20 > Softfork and hardfork are the 2 majors categories of consensus rules > change. Generally, softforks make some previously valid blocks invalid, > while hardforks make some previously invalid blocks valid. Bitcoin has > successfully introduced a number of new functions through softforks. A > built-in warning system is also available in many implementations to warn > users for the activation of any unknown softforks. >=20 > Some features, however, may not be easily introduced with a softfork. > Examples include expanding maximum block resources limits, and changing > the average block time interval. When such features are implemented with > a hardfork, existing full node implementations would consider such blocks > as invalid, and may even ban a peer for relaying such blocks. They are > effectively blind to such hardfork rule changes, leaving users to > unknowingly transact on a system with potentially different token value. > On the other hand, light nodes may blindly follow a hardfork with unknown > rule changes and lose the right to choose the previous system. >=20 > This BIP defines a change in consensus rules regarding to block nVersion, > and define a concept of generalized block header to implement a hardfork > warning system for full nodes and light nodes. >=20 > Definitions >=20 > Valid block > A block that satisfies all the consensus rules being enforced by a bitcoin > protocol implementation. An implementation may intentionally (e.g. a > light node) or unintentionally (e.g. unaware of a softfork) not enforcing > any part of the current netwrok rules. >=20 > Valid blockchain > A blockchain constituting of only valid blocks. >=20 > Best valid blockchain > The valid blockchain with highest total proof-of-work. >=20 > Valid blockchain fork > A valid blockchain sharing a common ancestral block with the best valid > blockchain, but with less total proof-of-work >=20 > Generalized block header > Any serialized hexadecimal data with exactly 80 bytes (byte 0 to byte 79). > The bytes 4 to 35 are the double-SHA256 hash of another generalized block > header. The bytes 72 to 75 are nBits, the target of this generalized > block header encoded in the same way as normal bitcoin block header. The > 2 most significant bits of the byte 3 are the hardfork notification bits. > The semantics of other data in a generalized block header is not defined > in any general way. It should be noted that a normal bitcoin block header > is a special case of generalized block header. >=20 > Generalized block header chain > A chain of generalized block header. A header chain of valid blocks is a > special case of a generalized block header chain. >=20 >=20 > Specifications >=20 >=20 > Block nVersion softfork >=20 > A softfork is deployed to restrict the valid value of block nVersion. Upon > activation, any block with the second highest nVersion bit set becomes > invalid (nVersion & 0x40000000) >=20 > This softfork will be deployed by "version bits" BIP9 with the name > "hfbit" and using bit 2. >=20 > For Bitcoin mainnet, the BIP9 starttime will be midnight TBC UTC (Epoch > timestamp TBC) and BIP9 timeout will be midnight TBC UTC (Epoch timestamp > TBC). >=20 > For Bitcoin testnet, the BIP9 starttime will be midnight TBC UTC (Epoch > timestamp TBC) and BIP9 timeout will be midnight TBC UTC (Epoch timestamp > TBC). >=20 > Any bitcoin implementation (full nodes and light nodes) supporting this > softfork should also implement a hardfork warning system described below. >=20 >=20 > Validation of generalized block header >=20 > A bitcoin protocol implementation should consider a generalized block > header as valid if it satisfies all of the following criteria: >=20 > =E2=80=A2 It is a descendant of the header of a valid block in a valid=20 blockchain > (the best valid blockchain or a valid blockchain fork). =E2=80=A2 It sati= sfies > the proof-of-work requirement: its double-SHA256 value MUST be smaller > than its target (encoded as nBits). =E2=80=A2 Its target MUST NOT be grea= ter than > the target of its last ancestral valid block by more than 1024 times. An > implementation may decide to use a different threshold (or dynamic > threshold), depending on its tolerance against potential DoS attacks by > generating many low difficulty headers. However, if the value is set too > low, a hardfork with lower difficulty may not be detected.[1] In general, > a bitcoin protocol implementation should keep an index of all known > generalized block header chains, along with the valid blockchain(s). > However, if a generalized block header chain is grown on top of a very > old valid block, with total proof-of-work much lower than the current > best valid bloackchain, it may be safely discarded. >=20 >=20 > Hardfork warning system in full nodes >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Setting of one or both hardfork notification bits is, as defined by BIP34 > and this BIP, a hardfork, and should be considered as an indication of a > planned hardfork. If a hardfork with unknown rules is happening without > any hardfork notification bits set, it is probably an accidental > consensus failure, such as the March 2013 fork due to a block database > bug (BIP50), and the July 2015 fork following the BIP66 activation.[2] >=20 >=20 > Hardfork with multiple valid blockchains > If a valid blockchain fork is emerging with non-trivial total > proof-of-work, a consensus disagreement may be happening among different > miners. >=20 > A wallet implementation should issue a warning to its users and stop > processing incoming and outgoing transactions, until further instructions > are given. >=20 > A mining implementation should issue a warning to its operator. Until > further instructions are given, it may either stop mining, or mine on top > of the best valid chain by its own standard. >=20 > Hardfork warning system in light nodes >=20 > 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. >=20 >=20 > Applications >=20 > Hardfork notification bits > There are 2 hardfork notification bits defined in this BIP. The higher bit > has been forbidden since BIP34, and the lower bit is disabled by this > BIP. For nodes supporting this BIP, the semantics of the 2 bits are the > same: a hardfork is happening. For legacy node, however, setting the > higher bit would make them fail to follow the hardforking chain. In a > soft-hardfork design (described below), the lower notification bit should > be used. The hardfork warning system is able to detect the following > types of hardforks: >=20 > Soft-hardfork (with the lower hardfork notification bit) > A soft-hardfork is a technique to implement a hardfork by pretending to > create blocks with only a zero output value coinbase transaction, and > commit the real transaction Merkle root in the coinbase scriptSig field. > With the lower hardfork notification bit set, a node following this BIP > will consider this as a hardfork and enter the safe mode, while a legacy > node not following this BIP will be effectively broken due to seeing the > continuously empty blockchain. >=20 > Redefining the nTime field > As the warning system does not interpret the nTime field, redefining it > through a hardfork would be detectable. For example, overflow may be > allowed to overcome the year 2106 problem. >=20 > 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. >=20 > Changing average block interval or difficulty reset > Since the warning system is not bound to a particular proof-of-work target > adjustment schedule, a hardfork changing the average block interval or > resetting the difficulty will be detectable. >=20 > 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. >=20 > 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. >=20 >=20 > Limitations >=20 > The only function of this system is to inform the users that a hardfork > might be happening and prompt for further instructions. It does not > guarantee that the hardfork will be successful and not end up with two > permanent incompatible forks. This requires broad consensus of the whole > community and is not solvable with technical means alone. >=20 > The following types of hardfork are not detectable with this warning > system: >=20 > =E2=80=A2 Changing of proof-of-work algorithm > =E2=80=A2 Changing the encoding of previous block header hash or nBits > =E2=80=A2 A coercive soft-hardfork without setting any hardfork notifica= tion bit >=20 >=20 > Backward compatibility >=20 > The softfork described in the BIP would only affect miners. As the > disabled nVersion bit is never used in the main network, it is unlikely > that any miner would unintentionally find an invalid block due to the new > rules. >=20 > BIP9 is disabled when any of the hardfork notification bits is set, which > may interrupt any ongoing softfork support signalling process. Developers > should pay attention to this when desinging a hardfork. For example, they > may redefine the counting of signal, or move the signalling bitfield to a > different location. >=20 > Legacy nodes would not be benefited from this softfork and warning system. > However, no additional risks are introduced to legacy node either. >=20 >=20 > Reference implementation >=20 > To be done >=20 >=20 > Footnotes >=20 >=20 > =E2=80=A2 ^ Please note that a hardfork may have lower difficulty but hi= gher > total proof-of-work, such as by decreasing the average block interval. = =E2=80=A2 > ^ In the March 2013 fork, pre-0.8 full nodes would see that as a hardfork > with unknown rules, while light nodes and 0.8.0 full nodes would see that > as multiple valid blockchains. In the July 2015 fork, BIP66-complying > full nodes would see that as a hardfok with unknown rules, while legacy > full nodes would see that as multiple valid blockchains. >=20 >=20 > Copyright >=20 > This document is placed in the public domain. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =2D-=20 Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel