Skip to content

Latest commit

 

History

History
102 lines (76 loc) · 3.48 KB

UIP-0003.md

File metadata and controls

102 lines (76 loc) · 3.48 KB
Raw

UIP-3: Unit-e Block Header to include SegWit Merkle Root

Author:   Julian Fleischer <[email protected]>
Status:   Proposed
Created:  2018-08-23

Context

Unit-e is a fork of bitcoin-core and uses the "esperanza" Proof-of-Stake consensus protocol instead of Bitcoin's Proof-of-Work scheme. The design is inspired by "PoS v3" with Ethereum's "Casper FFG". The implementation is based on particl-core.

The differences between these protocols and lessons learned during the development of bitcoin make us consider changes from the original bitcoin header format.

Bitcoin block header

The bitcoin block header is 80 bytes:

   0  vvvv pppp pppp pppp
  16  pppp pppp pppp pppp
  32  pppp mmmm mmmm mmmm
  48  mmmm mmmm mmmm mmmm
  64  mmmm tttt bbbb nnnn
vvvv : 4 bytes (int32_t)
block version number
pppp... : 32 bytes (uint256)
previous block hash
mmmm... : 32 bytes (uint256)
merkle tree root
tttt : 4 bytes (uint32_t)
timestamp
bbbb : 4 bytes (uint32_t)
bits (difficulty)
nnnn : 4 bytes (uint32_t)
nonce

Particl block header

The bitcoin block header is 112 bytes:

   0  vvvv pppp pppp pppp
  16  pppp pppp pppp pppp
  32  pppp mmmm mmmm mmmm
  48  mmmm mmmm mmmm mmmm
  64  mmmm wwww wwww wwww
  80  wwww wwww wwww wwww
  96  wwww tttt bbbb nnnn

The additional field is:

wwww... : 32 bytes (uint256)
segregated witnesses merkle root

SegWit in Bitcoin

Peter Wuille explains some design decisions regarding SegWit in Bitcoin on Bitcoin StackExchange:

Why the witness Merkle root is stored in the coinbase: easiest deployment for miners

Lastly, we need a place to embed the witness Merkle root hash that affects the block hash. Using the block header would have been perfect, but there is no way to add data there without breaking every piece of Bitcoin infrastructure.

The only place flexible enough for storing that data is in a transaction. A special transaction could have been added which contains the commitment, but transactions bring extra overhead. They need inputs and outputs, which need to come from somewhere and go somewhere.

Because of that, the only choice remaining was to embed the commitment in an existing transaction. The coinbase transaction is the logical choice - it is already created by miners anyway, and adding a dummy output to it has low resource costs (due automatic removal of OP_RETURN outputs from the UTXO set).

Decision

We will adopt the particl block header structure, which makes the witness merkle root part of the block header.

Consequences

As Peter Wuille points out:

there is no way to add data there without breaking every piece of Bitcoin infrastructure

Doing this change in bitcoin would require the coin to hardfork. Luckily we're not live yet, so we can still do such a breaking change in unit-e. It will require us to change most of the tests though (especially the fixtures), which requires a bit of effort from our side.

Reference implementation

Unit-e pull request

Changelog

  • 2019-04-16 Added reference implementation and changed status to proposed
  • 2018-12-12 Moved to UIP repository as UIP-3
  • 2018-09-04 Accepted as ADR-3