Considering all the recent block size drama, it's probably not a good idea to be overly optimistic.
They are hopefully not that much of a major issue, if there is near total agreement.
The header will have the following fields:
1. version (2): unsigned integer. Voting is moved to coinbase. 65536 versions should be enough forever.
2. prev_block (32): hash of the previous block
3. merkle_root (32): Root of merkle-sum-tree for fee, tx size, sigop counts, etc, so compact proofs could be produced for these parameters.
4. timestamp (5): unsigned integer. Enough for >34,000 years.
5. nonce (9): While a 1TH/s miner will exhaust 5 bytes of nonce in 1 second, we won't need longer nonce until miners become 4 billion times faster. (Current ASIC is only 1 million times faster than CPU, so we are taking about >1018 times faster than current CPU. This may happen only if SHA256 is partially cracked but then we need another algorithm)
6. coinbase (varint): the coinbase will become part of the header, which includes:
6a. height (4 currently): same as BIP34, consume 4 bytes for the following 300 years.
6b. bits (4): target in compact form
6c. arbitrary data: voting for fork proposals, merge mining, etc.
1. version (2): unsigned integer. Voting is moved to coinbase. 65536 versions should be enough forever.
2. prev_block (32): hash of the previous block
3. merkle_root (32): Root of merkle-sum-tree for fee, tx size, sigop counts, etc, so compact proofs could be produced for these parameters.
4. timestamp (5): unsigned integer. Enough for >34,000 years.
5. nonce (9): While a 1TH/s miner will exhaust 5 bytes of nonce in 1 second, we won't need longer nonce until miners become 4 billion times faster. (Current ASIC is only 1 million times faster than CPU, so we are taking about >1018 times faster than current CPU. This may happen only if SHA256 is partially cracked but then we need another algorithm)
6. coinbase (varint): the coinbase will become part of the header, which includes:
6a. height (4 currently): same as BIP34, consume 4 bytes for the following 300 years.
6b. bits (4): target in compact form
6c. arbitrary data: voting for fork proposals, merge mining, etc.
Moving the data to the Merkle tree means that it is completely transparent to mining hardware.
Code:
Primary Header
int(4) version: The version number
int256(32) prev_block: Hash of the previous block's header
int256(32) aux_header: Hash of the auxiliary header
int(4) timestamp: Lower 4 bytes of timestamp
int(4) bits: Difficulty target (compact)
int(4) main_nonce: Primary nonce
Auxiliary Header
int256(32) merkle_root: The merkle root
var_str(1+) aux_data: The auxiliary data
Auxiliary Data (initial version)
short(2) timestamp_upper: Upper 2 bytes of timestamp
long(8) aux_nonce: Secondary nonce
int(4) height: Block height
int(4) vote_start: Voting data starts at this byte position
var_str(1+) votes: Voting data
aux_header = Hash256(merkle_root | Hash(aux_data))
block_hash = Hash256(version | prev_block | aux_header | timestamp | bits | main_nonce)
The advantage of arranging it this way is that it is fully backward compatible with current mining hardware. It even supports current merkle blocks, since the new auxiliary data is added into the Merkle tree, rather than as new fields.
Additionally, the aux_data field is defined as a variable length string. This means that if new fields are added, they can be handled by legacy clients.
The voting vector can specify a start position to skip obsolete vote positions.
Alternatively, the vote data could be a series of var_ints. The first int would be the vote_id and the 2nd would be the miner's choice.
)
