Introduction

Prior to this work, there were two primary proposed implementations of sidechains.

1. SPV proof-based sidechains, as described in the original sidechains paper. Sidechains have their own proof-of-work, and sections of the sidechain header chain are published on the mainchain in a "compact SPV proof" which attests that a side-to-main withdrawal exists on the sidechain.
2. Drivechains, as described in the drivechains website. Sidechains are merge-mined, and the existence of side-to-main withdrawals on the sidechain are attested to by miner voting on the mainchain. Sztorc's proposal also includes "blind" merge mining, where the sidechain block assembler is separate from the mainchain miner, and pays the latter to commit to "correct" block header hashes.

Driveproof combines elements of both proposals. Specifically:

1. Sidechains are merge-mined.
2. The merge-mining does not commit to header hashes as in traditional merge-mining; instead, sidechain headers are reduced to the minimum, and the entire sidechain header is published on the mainchain.
3. As the chain of headers is published on the mainchain continuously as part of merge-mining, an SPV proof is being continuously published; there is no need to compact an SPV proof at withdrawal, since the mainchain already has the SPV proof as part of merge-mining the sidechain.
4. Sidechains may be "blind" merge-mined, i.e. arbitrary owners of maincoin may pay miners to insert particular block headers onto the sidechain; this means the economic majority controls the sidechain, in a way that is not done in drivechains, since the miner voting of drivechains is eliminated in favor of economic-majority voting for the true history of the sidechain.

Sidechain Headers

At its core, a blockchain is simply a Merklized singly-linked list, with the genesis block as the end-of-list indicator.

At an absolute minimum, a blockchain header needs to contain only two things: a commitment to the transactions in the block, and a commitment to the previous blockchain header.

We may argue, perhaps, that new innovations may require that sidechains have additional fields in their headers, and that a one-size-fits-all is too much of a restriction on sidechains.

I would then point out the fields below:

1. extraNonce
2. SegWit witness commitment

In Bitcoin, because the header format must be fixed forever unless hardforked, both of the above fields are not in the block header. Instead, they are in the coinbase transaction. The same technique can be used by sidechains: header fields may be placed in a sidechain's equivalent of a coinbase transaction.

Indeed, sidechain Merkle trees need not be balanced. Sidechains may have a special "transaction" which is not really a transaction, which contains the data the header would have contained. This could be the sole child of one side of the root Merkle tree node, with the other child being the root of the balanced Merkle tree of transactions.

Thus, in driveproof, a sidechain block header is composed of:

1. sidechainId, 16 bytes that identify a sidechain.
2. hashMerkleRoot, 32 bytes that commit to the sideblock's transactions.
3. hashPrevBlock, 32 bytes that are the hash of the previous sidechain block header.

Sidechain Miners and Mainchain Miners

In driveproof, sidechain miners "hire" mainchain miners to insert entire sidechain headers on the mainchain. This is why this technique is called "sidechain headers on mainchain."

In-progress

This writeup is in progress. See the links below for the discussion on bitcoin-dev: