path: root/2b/035f88240d228721b537e23f892c176d637f15

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 B514141C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Apr 2017 20:13:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB738164
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun,  2 Apr 2017 20:13:30 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
	mx.zohomail.com with SMTPS id 1491164006790535.4334878335187;
	Sun, 2 Apr 2017 13:13:26 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: <2D094CEC-3756-45B0-970F-1EB33DF352C5@xbt.hk>
Date: Mon, 3 Apr 2017 04:13:23 +0800
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
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] BIP draft: Extended block header hardfork
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: Sun, 02 Apr 2017 20:13:31 -0000

This is the first of a series of BIPs describing my =E2=80=9Cspoonnet=E2=80=
=9D experimental hardfork. Recently many bitcoin businesses expressed =
their requirements for supporting a hardfork proposal. While it is =
proven to be extremely difficult to obtain community-wide consensus, =
spoonnet fulfills all the commonly requested features, including =
deterministic activation logic, strong and simple 2-way replay =
protection, wipe-out protection, and predictable resources use. A few =
more BIPs are coming to describe these features.

The activation is purely based on flag day. Since it is very difficult =
to measure community consensus on-chain, this may only be done =
off-chain, and everyone switch to the new software when the vast =
majority agree. This is more a social issue than a technical one.

Reference implementation for consensus codes could be found at: =
https://github.com/jl2012/bitcoin/tree/spoonnet2 . This does not include =
mempool, wallet, and mining support. Mempool and wallet support are more =
tricky due to replay attack protection.

BIP: ?=20
Layer: Consensus (hard fork)=20
Title: Extended block header hardfork=20
Author: Johnson Lau <jl2012@xbt.hk>=20
Comments-Summary: No comments yet.=20
Comments-URI:=20
Status: Draft=20
Type: Standards Track=20
Created: 2017-03-31=20
License: BSD-2-Clause


Abstract

This BIP proposes a flexible and upgradable extended block header format =
thorough a hardfork.

Motivation

In the current Bitcoin protocol, the block header is fixed at 80 bytes =
with no space reserved for additional data. The coinbase transaction =
becomes the only practical location for new consensus-critical data, =
such as those proposed by BIP100 and BIP141. Although this preserves =
maximal backward compatibility for full nodes, it is not ideal for light =
clients because the size of coinbase transaction and depth of Merkle =
tree are indefinite.

This BIP proposes an extended block header format with the following =
objectives:

	=E2=80=A2 To provide a flexible header format which is easily =
upgradeable with softforks.
	=E2=80=A2 Old light nodes following the hardfork chain if it has =
most proof-of-work, but not seeing any transactions.
	=E2=80=A2 Being compatible with the Stratum mining protocol to =
avoid mining machine upgrade.
	=E2=80=A2 Having a deterministic hardfork activation.
	=E2=80=A2 Being a permanent hardfork, as supporting nodes will =
not accept blocks mined in old rules after hardfork is activated.

Specification

The following rules are activated when the median timestamp of the past =
11 blocks is equal to or greater than a to-be-determined time and after =
activation of BIP65.


	=E2=80=A2 the nVersion of the block header MUST have the most =
significant bit (the sign bit) signalled.
	=E2=80=A2 for the purpose of counting softforks proposal =
signalling (BIP9), the sign bit is ignored.
	=E2=80=A2 segregated witness MUST be enabled, if it had not been =
already activated through the BIP9 mechanism.
	=E2=80=A2 the witness of the first input of the coinbase =
transaction MUST have exactly one stack item (the "extended header"), =
with the following data:
		=E2=80=A2 bytes 0 to 3: nHeight MUST be equal to the =
height of this block (signed little endian)
		=E2=80=A2 bytes 4 to 5: MUST be exactly 0x0000
		=E2=80=A2 bytes 6 to 53: extra data with no meaning in =
Bitcoin protocol
		=E2=80=A2 bytes 54 to 85: hashMerkleRoot the transaction =
Merkle root (calculated in the same way as the original Merkle root in =
the block header)
		=E2=80=A2 bytes 86 to 117: hashWitnessRoot the witness =
Merkle root (NOT calculated in the way described in BIP141)
		=E2=80=A2 bytes 118 to 121: nTx MUST be equal to the =
number of transactions in this block (unsigned little endian, minimum 1)
		=E2=80=A2 bytes 122 to 129: nFees MUST be equal to the =
total transaction fee paid by all transactions, except the coinbase =
transaction, in the block (unsigned little endian)
		=E2=80=A2 bytes 130 to 137: nWeight MUST be equal to or =
greater than the total weight of all transactions in the block (to be =
described in another BIP. NOT calculated in the way described in BIP141)
		=E2=80=A2 bytes 138+ : Reserved space for future =
upgrades
	=E2=80=A2 bytes 36 to 67 in the block header, the place =
originally for the hashMerkleRoot is replaced by the double SHA256 hash =
of the extended header.
	=E2=80=A2 size of the extended header MUST be at least 138 =
bytes.
	=E2=80=A2 wtxid of the coinbase transaction is calculated as if =
the witness of its first input is empty.
	=E2=80=A2 the hashWitnessRoot is calculated with all wtxid as =
leaves, in a way similar to the hashMerkleRoot.
	=E2=80=A2 the OP_RETURN witness commitment rules described in =
BIP141 is not enforced.
	=E2=80=A2 The witness reserved valued described in BIP141 is =
removed from the protocol.
A special extheader softfork is defined, with the following BIP9 =
parameters:
	=E2=80=A2 bit: 15
	=E2=80=A2 starttime: 0
	=E2=80=A2 timeout: 0xffffffff
Until the extheader softfork is activated, the following extra rules are =
enforced:
	=E2=80=A2 nWeight MUST be exactly equal to the total weight of =
all transactions in the block
	=E2=80=A2 size of the extended header MUST NOT be larger than =
152 bytes
Activation of the special extheader softfork is independent to the =
activation time of the hardfork. If the special softfork is activated =
before the hardfork, the aforementioned extra rules will not be enforced =
when the hardfork is activated. Nodes that are not aware of the new =
rules should consider extheader softfork as an unknown upgrade and issue =
warnings to users accordingly.

Rationale

This hardfork employs a simple flag day deployment based on the median =
timestamp of previous blocks. Beyond this point, supporting nodes will =
not accept blocks with original rules. This ensures a deterministic and =
permanent departure with the original rules.

The witness field of the coinbase input is used as a convenient unused =
space to store the extended header. For any other purposes the extended =
header is not considered as part of the coinbase transaction (it is =
removed when the wtxid is calculated) This design minimizes the changes =
in the peer-to-peer protocol between full nodes, as no new message type =
is required to transmit the extended header. However, a new protocol =
message is still needed for serving light nodes.

Committing to the block height allows determining the value before all =
parental headers are obtained.

By fixing the bytes 4 to 5 as 0x0000, in the worst case an unupgraded =
light node may consider the block has only one transaction with no input =
and output, and will not see any real transactions.

The 48 byte extra data field is reserved for miners for any purposes and =
designed to be compatible with the Stratum mining protocol. Miners are =
expected to use 4 to 16 bytes as extra nonce, and 32 to 44 bytes for =
merge mining. This requires a hardfork for all AuxPOW blockchains, while =
significantly reduces the size of AuxPOW block headers.

hashMerkleRoot is relocated to the extended header, followed by =
hashWitnessRoot. The new structure allows hashWitnessRoot committing to =
the wtxid of coinbase transaction with extended header removed.

Committing to the number of transactions allows light nodes to determine =
the Merkle tree structure easily.

Committing to the transaction fees and block weight provides information =
for fees estimation.

The reserved space (16 bytes until the extheader softfork is activated) =
MUST NOT be used without community consensus. It should be primarily =
used for consensus critical commitments and network status data for =
light nodes. Other arbitrary data should use the extra data field in =
extended header or the scriptSig of the coinbase transaction.

The special extheader softfork allows future protocol upgrades to =
increase the size of the extended header and redefine the calculation of =
block weight in a backward compatible way.

Other proposed hardfork changes are described in other BIPs.

Compatibility

This is a hard forking change, which breaking compatibility with old =
full node and light node. It should not be deployed without widespread =
consensus.

Old full nodes will consider the block header nVersion as invalid and =
refuse the follow the hardfork chain.

Depending on the design of light nodes, they may consider the hardfork =
chain as the best chain if it has the most total proof-of-work. However, =
they will not see any transactions in the chain and cease to properly =
function until either upgrading to the new rules, or rejecting the new =
rules with the negative block header nVersion.

Reference implementation

https://github.com/jl2012/bitcoin/tree/spoonnet2

Copyright

This BIP is licensed under the 2-clause BSD license.=