Bitslog

As segwit has been merged by Bitcoin Core, and the block size increase seems it will never be merged, I perceive waters are calmer. Not because there is consensus, but because it feels there will never be. But ScalingBitcoin Milan conference is close, tomorrow precisely. So let’s work on other ways to expand Bitcoin without block size increase, and relying only on soft-forks, which are much less controversial.

The good news is that segwit is prepared to easily do soft-forks, so new opportunities arise. During this last year, I’ve analyzed in depth the different ways to create two-way pegged blockchains, and the two major proposals to achieve a two-way peg in a (mostly) decentralized way are sidechains and drivechains. Sidechains are based on cross-chain consensus validation through SPV and reorganization proofs (an idea that dates back to my P2PTradeX protocol), while drivechains are based on miners being consensus proxies. There are a couple of important differences between the two approaches: on one side sidechains “in abstract” seems to provide greater decentralization, as Bitcoin miners do not take any special role, but the users themselves are incentivized to send SPV and reorganization proofs to the blockchain. On the contrary, drivechains require that miners follow add-hoc protocols to obey the commands of a secondary blockchain consensus and engage in an on-chain coordination protocol to acknowledge the commands (the state) of the second blockchain. However, once you get to the sidechain design details, this apparent benefit of complete decentralization fades rapidly. To be fully decentral, a secondary blockchain must have a decentralized consensus protocol. The only consensus protocol that can be validated by Bitcoin currently is proof-of-work. Supporting other external consensus protocols would require either coding one opcode per secondary chain consensus system (impractical and limited) or extending the Bitcoin scripting system to “Turing-completeness” so users can code the consensus algorithm itself (undesired and risky). So we must assume the sidechains will use Bitcoin-based PoW for consensus (SHA256D), but in this case the only way to secure the secondary blockchain without reducing the security of the primary chain is by merge-mining. Now you may already see the problem: this gives 51% of Bitcoin miners censorship power over the reorganization proofs that can be included, which means that 51% of Bitcoin miners can double-spend the funds on the sidechain. This also means that the decentralization and security properties of the merge-mined sidechain are almost exactly the same as the security of the drivechain! There is one minor difference though: in a merge-mined sidechain, 51% of the miners can double-spend their own bitcoins (current or past), while in a drivechain 51% of the miners can spend all the bitcoins in existence in the secondary blockchain. But there are huge advantages of drivechains: it is a much less complex beast.  The cross-chain transfer transactions are very short in case of a drivechain (so they pay normal fees), but can be very long (and pay huge fees) in case of a sidechain. As an example RSK‘s state-less implementation of a drivechain add-on for Bitcoin has only 600 lines of code (plus much more of unit tests code, of course).

At the end, what RSK did to improve drivechains to have the “pure” sidechain-like security is to add a second layer of security: the requirement that cross-chain transactions are also signed by a set of notaries (a threshold signature), and the set of notaries will not sign a double-spend, nor a any spending that was not authorized by the corresponding owner of the funds in the secondary chain.

I’m leaving for the ScalingBitcoin opening party. I hope to see you there and have fun. I thank the organizers in advance for pushing forward research and development in Bitcoin.  In my next post, hopefully when I came back from the party, I will talk about the different implementations of sidechains in existence (basically RSK’s and Truthcoin’s). Arrivederci!