Proposals and Implementations of Bitcoin Sidechains

Blockchains and Sidechains

Bitcoin in its original, unmodified state has enormous utility. When it was created, the original designer(s) could not account for everything that would transpire after its launch. There are many aspects of the software that are final and unalterable. The consequences of final variables of Bitcoin results in a hard forks. In the occurance of a hard fork, the nodes running modified software sacrifice their ability to interact with the nodes running the original software. The altered nodes begin creating blocks differently and within six blocks there are two block chains - the original and the forked chain.

What if rather than forking Bitcoin and creating a separate network, there was a way to modify the Bitcoin software, create an adjacent block chain, and facilitate transfers between the two chains? Such a system would have a multitude of uses. By 2014, a whitepaper was published, which outlined the purpose of such an invention. Since then, the idea has taken on the name drivechain and developers have been ironing out if and how it should be implemented.

In order to function, drivechain uses a multi-signature script called a Two-Way-Peg. When a user seeks to transfer funds to a side chain, they would send the funds to the two-way peg. The two-way peg allows for the virtual transfer of funds across chains, on the premise there would be an address on the sidechain receiving the transaction. Implementing the two-way peg is the harder part. This issue is elaborated on in original whitepaper referenced in the emails. The authors purposed two solutions for creating a functional two-way peg. (1) Through a soft fork, an addition operation code will be added to Bitcoin. The operation code would read OP_SIDECHAINPROOFVERIFY and would be designed to verify SPV (Simplified Payment Verification) proofs. (2) Use a third party to manage the additional key. According to the whitepaper, using a third party “is very similar to the approach of creating a multi-signature off-chain transaction system”.

There are interesting issues a drivechain could create. In section 4.3 of the whitepaper, mining centralization is considered to be a potential impact of sidechains. The argument is that miners could reuse their work on many or all sidechains in the form of merged mining. Another argument is that hashrate could oscillate between chains, where miners seek the highest rewards. This event occurred in November 2017 when a significant amount of hashpower shifted from Bitcoin to a fork of Bitcoin. The hashpower eventually returned to Bitcoin, but the occurrence of such an event paints a clear picture of how damaging sidechains could be.


In an attempt to address these issues, Paul Sztorc, a developer behind drivechain, explained his idea of its implementation in series of emails on the bitcoin-dev mailing list on December 1, 2017:

My vision… is of a stable, conservative Bitcoin Core with 3-8 sidechains, of which at least one is rather experimental, and at least one of which has its own sidechains.

The documentation Sztorc provided describes how to implement drivechain. The modification to the Bitcoin protocol would occur in two stages, or two BIPs (Bitcoin Improvement Protocol). Currently, the purposed BIPs have not been assigned number. The first BIP is titled Hashrate Escrow. The second is Blind Merged Mining. Sztorc also included the following reference website, explaining drivechain in greater detail, along with the source code for two reference implementations:

  1. mainchain
  2. sidechain

The series of emails began when Paul emailed two proposals for sidechains, including an implementation.

The Drivechain Debate

The drivechain idea was presented as two concepts:

  • The “hashrate escrow” which allows users to make their transactions vulnerable to reduced-security SPV proofs.
  • The “blind merged mining” idea which is basically a modern version of merged-mining that is specialized in order to make asymmetric sidechains as tame as possible.

The hashrate escrow proposal is a way of solving the federation peg problem. Instead of using a third party for the two-way peg, miners sign the multi signature transaction by directing hashpower towards it.

Matt Corallo critiqued the proposal, describing aspects of it “disappointing” and “sub-optimal”:

I’m rather [disappointed] by the amount of data that is going into the main chain here. Things such as a human readable name have no place in the chain… Given the lack of convincing evidence of that “Risk of centralisation of mining” drawback in section 4.3 of the sidechains paper has been meaningfully addressed, I’d say its pretty important that new sidechains be an incredibly rare event.

The semantics of the deposit process seem very suboptimal. You note that only one user can deposit at a time, but this seems entirely unnecessary.

While Corallo was not intrigued with the post, Paul Sztorc affirmed he had solved the centralization attack:

It allows miners to ignore the resource-cost of the sidechain, and therefore smaller miners will not be at a revenue-disadvantage.

Current State of Development

Many comments have already been submitted in the thread but no BIP number have been assigned yet. Some feedback from other teams implementing sidechains might be needed, as Matt Corallo stated:

Process note: It looks like the BIPs have never been posted to bitcoin-dev, only high-level discussion around the idea. As I understand it, this is not sufficient for BIP number assignment nor (realistically) sufficient to call it a hard “proposal” for a change to consensus rules.

Would love to get feedback from some others who are looking at deploying real-world sidechains, eg the RSK folks. We can’t end up with two protocols for sidechains in Bitcoin.

Long Term Prospects of Sidechain Technology

The concept of sidechain has been backed with financial investment. A company, RSK, has invested an enormous amount of time, effort, and manpower into developing a sidechain for the Bitcoin network. RSK boasts their sidechain is multitudes faster than the Bitcoin blockchain and their platform can execute far more complex smart contracts. The company even went as far as to call their token SBTC for “smart Bitcoin”. On the other hand, RSK does not intend to mint its own coin and plans on operating by tapping into the liquidity of Bitcoin via their two-way federated peg. This originality is a breath of fresh air for many in the cryptocurrency space looking for genuinely authentic inventions.

Putting it all Together

Due to the ongowing success of the Lightning Network, sidechains may appear to be a dying fad. In a desperate attempt to find any and all scaling solutions, sidechains had their time in the spotlight. But, it is important to remember the fundamental utility of sidechains is not for scaling. It is for network upgrading. Eventually, collisions could be discovered in the SHA256 hashing algorithm (it has already happened for SHA1). The tracability of Bitcoin could increase. A multitude of other security related issues could arise, requiring a full network upgrade. In such a situation, a sidechain with upgraded protocols would be created followed by a multi-year asset transfer to the new chain, most likely facilitated by the Lightning Network, layers away from the end user.

Support us and the authors of this article by donating to the following address:


Comments powered by Talkyard.