path: root/ac/8145862dc4560453f6351489327e18758e083f

Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 54D92B5E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  1 Dec 2016 19:51:58 +0100 (CET)
From: Tom Zander <tomz@freedommail.ch>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jl2012@xbt.hk>
> 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