path: root/af/be2e96003c91827e1ef4e1e54c472ba03509fa

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5967E728
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  1 Dec 2016 17:20:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender163-mail.zoho.com (sender163-mail.zoho.com
	[74.201.84.163])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CDF5FA0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  1 Dec 2016 17:20:39 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
	mx.zohomail.com with SMTPS id 1480612835942194.70369902059394;
	Thu, 1 Dec 2016 09:20:35 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk>
Date: Fri, 2 Dec 2016 01:20:31 +0800
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [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 17:20:41 -0000

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.

For better formatting, visit github
https://github.com/jl2012/bips/blob/hfwarning/bip-hfwarning.mediawiki



BIP: ?
Title: Hardfork warning system
Author: Johnson Lau <jl2012@xbt.hk>
Status: Draft
Type: Standard
Created: 2016-12-01

Abstract

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.

Motivation

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.

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.

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.

Definitions

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.

Valid blockchain
A blockchain constituting of only valid blocks.

Best valid blockchain
The valid blockchain with highest total proof-of-work.

Valid blockchain fork
A valid blockchain sharing a common ancestral block with the best valid =
blockchain, but with less total proof-of-work

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.

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.


Specifications


Block nVersion softfork

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)

This softfork will be deployed by "version bits" BIP9 with the name =
"hfbit" and using bit 2.

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).

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).

Any bitcoin implementation (full nodes and light nodes) supporting this =
softfork should also implement a hardfork warning system described =
below.


Validation of generalized block header

A bitcoin protocol implementation should consider a generalized block =
header as valid if it satisfies all of the following criteria:

	=E2=80=A2 It is a descendant of the header of a valid block in a =
valid blockchain (the best valid blockchain or a valid blockchain fork).
	=E2=80=A2 It satisfies 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 greater 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.


Hardfork warning system in full nodes

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.

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.

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]


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.

A wallet implementation should issue a warning to its users and stop =
processing incoming and outgoing transactions, until further =
instructions are given.

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.

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.


Applications

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:

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.

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.

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.

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.

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.

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.


Limitations

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.

The following types of hardfork are not detectable with this warning =
system:

	=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 =
notification bit


Backward compatibility

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.

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.

Legacy nodes would not be benefited from this softfork and warning =
system. However, no additional risks are introduced to legacy node =
either.


Reference implementation

To be done


Footnotes


	=E2=80=A2 ^ Please note that a hardfork may have lower =
difficulty but higher 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.


Copyright

This document is placed in the public domain.=