Bitcoin vs Banking [infographic]
Disclosure: the author of this article is the founder and Chief Scientist of the Ethereum project
Last week, Adam Back and Austin Hill came out with an announcement on Let’s Talk Bitcoin, in which they announced their newest project: “sidechains”. The idea, they described, would allow for the existence of alternative blockchains, perhaps with different rules allowing various kinds of additional features or transaction types, but with a currency unit whose value is pegged to that of the bitcoin. The intent is to allow experimentation with different extensions to the Bitcoin protocol, using separate networks to avoid any risk to Bitcoin itself, while still using the same underlying currency unit. As soon as the idea was announced, there has been a large amount of public interest in the concept, and has brought renewed hope that the Bitcoin protocol can potentially become much more powerful than it is today.
The idea behind sidechains is not new; the concept has been around since at least last year in December, and a precursor to the idea has been around for several years before then. The precursor, a protocol known as one-way pegging, was a mechanism that would theoretically be used to manage a transition from “Bitcoin 1.0″ to “Bitcoin 2.0″, and worked as follows. Suppose that, in Bitcoin 1.0, 13 million currency units have already been issued through mining, with 8 million still left to give out. The distribution model for BTC2.0 would release 8 million units through mining, according to the exact same schedule as BTC1.0 after that point, but the other 13 million would be distributed through a mechanism known as “proof-of-burn”.
Essentially, one would take one unit of BTC1.0, send it to an unspendable address (eg. 1111111111111111111114oLvT2), and submit a cryptographic proof that this transaction took place, signed by the same private key that sent the transaction, as a transaction into Bitcoin 2.0. According to the Bitcoin 2.0 protocol, this would entitle the user to receive one unit of 2.0. This is called a “one-way peg” because the value of one BTC2.0 can be at most equal to one BTC1.0; otherwise, people would arbitrage the difference by converting the bitcoins over at the 1:1 rate. However, aside from selling BTC2.0 for BTC1.0 on the market, there is no way to go back, so if the experiment fails the value of BTC2.0 could drop to zero.
Bitcoin sidechains use an improved version of this system called “two-way pegging”, which works as follows. In order to receive one unit of BTC2.0, one would need to take one unit of BTC1.0 and send it into a “script” which we will call X and leave undescribed for now. A script in Bitcoin is an address that, instead of being owned by a private key, essentially acts as a lockbox that unlocks the bitcoins only when given a transaction that satisfies certain conditions. For example, one can have a script that unlocks the funds to the first person who submits a fifty-digit prime number consisting entirely of the digits 3 and 5. Making the transaction, and publishing a cryptographic proof that such a transaction was made, into the Bitcoin 2.0 blockchain entitles the user to one unit of BTC2.0.
Now, the definition of X is simple: X unlocks the funds (remember, this is one unit of BTC1.0) if given a valid cryptographic proof that the sender destroyed one unit of BTC2.0. Thus, there exists a mechanism for converting BTC 1.0 to BTC2.0, and that very mechanism creates another mechanism, limited in value to the total number of BTC2.0 created, which can be used to convert BTC2.0 back to BTC1.0.
Under the Hood
The mechanism that these “cryptographic proofs” use relies on a cryptographic construction used in Bitcoin called a Merkle tree. In a Bitcoin block, instead of simply having every transaction the block block directly, only a single 32-byte hash is actually included in the block header. This 32-byte hash is itself calculated from two other 32-byte hashes, each of which comes from two other 32-byte hashes, and so forth until finally the values at the bottom are the transactions themselves. It is precisely the point of this mechanism to allow for the existence of compact proofs that a specific transaction is in a specific block; all that one needs is the one branch of hashes going up from that transaction to the root node, or a total of 10 hashes for 1000 transactions or 20 hashes for one million transactions. This is impossible to forge; if you try to change even a single transaction in the tree, the changes propagate upward through the hashes until finally the root node ends up completely different.
However, this does not solve the problem completely; all it tells you is that some block, somewhere, contains a given transaction. It does not tell you that the transaction is in the main chain; in reality, the same bitcoins used in the transaction could have already been sent to a different source, making the transaction invalid. There are two ways to solve this. One approach is for the proof mechanism in Bitcoin 2.0 to ask not just for the Merkle tree branch, but also for the blockchain going back six blocks, much like a merchant asking for six confirmations, using mining power as a proxy for validity. For higher security, a much larger number of blocks like sixty can be required.
Challenges
The above mechanism, however, as described is highly imperfect. When an ordinary merchant asks for six confirmations, pulling off a double-spend attack requires producing six blocks faster than the rest of the network combined in real time, a task which requires at least 30% of total network hashpower to work with any non-negligible success rate. With the above described two-way-pegging mechanism, however, a malicious miner with even 1% of hashpower can generate six blocks, or even sixty blocks, eventually, and then use these blocks to fraudulently claim all BTC1.0 that have been put into the BTC2.0 lockboxes (or, in the other direction, fraudulently claim an unlimited number of BTC2.0). One possible patch that may come to mind is requiring the same person who created the lockbox to open it, thereby limiting the amount of damage that can be done per person, but this will not solve the problem because the malicious miner can easily collude with anyone else. The fundamental problem, that there is no way to come up with a mechanism for validating the blockchain that does not update itself over time, is either very difficult to solve or likely cannot be solved while staying purely within Bitcoin’s “static lockbox” scripting paradigm.
Another approach, one that can solve this problem without excessive difficulty, is more intricate and intrusive. It requires essentially including what is called a “light client” for Bitcoin 1.0 into Bitcoin 2.0. The light client is most easily described as a long-running “contract”, a program on the blockchain with a large amount of internal state that runs every time a transaction gets sent to it, that would accept blocks and verify block headers in exactly the same way that a Bitcoin client on your mobile phone would. This contract would then keep a running list of all block headers in Bitcoin 1.0, and in order to receive one BTC2.0 one would need to submit a cryptographic proof that you made the required transaction in BTC1.0 into the contract, alongside a security deposit of 0.1 BTC2.0.
The contract would check that the proof is valid, ends up at a block that is in the contract’s own internal mini-blockchain, and then wait one of two things happened. First, once sixty more Bitcoin 1.0 blocks get added into the contract, it would release one unit of BTC2.0 to the sender plus the security deposit. Alternatively, if someone else submits a cryptographic proof that the transaction is invalid for whatever reason (eg. it spends bitcoins that don’t exist) within that time, then they would receive the security deposit. This would solve the security problem, but has one important flaw: it cannot be done within the Bitcoin protocol as it stands. It is fairly easy to implement in a protocol like Ethereum, because it is specifically designed for contracts, but Bitcoin’s scripting functionality does not allow for the existence of contracts that have internal state, so doing this inside of Bitcoin would require a very substantial change to the Bitcoin 1.0 protocol. Ultimately, the approach taken by Austin Hill and Adam Back may not look exactly like either of these strategies; however, the sheer complexity of the problem shows that there are still many challenges that lie ahead.
Mining
Another important question is: how will these side-chains be secured? The standard mechanism for securing a blockchain is mining, but mining requires a mechanism for rewarding miners on that chain. In a side-chain, every unit of the side-chain currency must be backed by a script-lockbox containing a unit of BTC on the Bitcoin blockchain, so there is no simple opportunity to issue side-chain currency units out of nowhere. There are two possibilities for this: demurrage (ie. a percentage-per-year tax on all BTC on the side-chain), and transaction fees. However, both of these provide a fairly low amount of revenue, and so it is not at all certain that plain old independent mining will solve the problem.
There are two approaches to get around this issue. One approach is to have the side-chain be secured by proof of stake, using the small revenue from transaction fees to compensate participating stakeholders with an interest rate. However, this approach would be very difficult to implement into a side-chain, because the computations involved in validating proof-of-stake are likely too complex to effectively implement directly on a blockchain. The other approach, and the one promoted by Adam Back and Austin Hill, is called “merge-mining”; essentially, miners include in Bitcoin blocks data from both the Bitcoin block and the Namecoin block, allowing miners to provide security for both chains at the same time using the same computational effort.
However, as argued by Bitcoin developer Peter Todd, the concept of merge-mining does have one very important security flaw: unless the majority of Bitcoin miners agree to merge-mine a particular chain, that chain is arguably not secure at all. To understand why, first consider the case of a more traditional altcoin, in our example running SHA256 for simplicity (if the altcoin uses a custom algorithm, then Litecoin miners can pull off the attack instead). If the altcoin has 5% of the hashpower of Bitcoin, then in order to attack the chain via a double-spend at least 5% of the Bitcoin network’s power would need to temporarily redirect itself to mining on the altcoin. This is potentially possible, but is a costly move: while the attack is in place, the Bitcoin miners would lose the revenue from mining on Bitcoin. In the case of a merge-mined side-chain, however, mining on the mainline of a side-chain or attacking it are both cost-free, so there would be no economic disincentive to attacking the alternative chain. This is not a mere conjecture; there have been actual examples of mining pools attacking merge-mined chains in reality.
Aside from security, this dependence on merge-mining also exposes another worrying limitation of the side-chains idea: while the spirit of cryptocurrency is arguably that of permissionless innovation, creating a side-chain requires the permission and active assistance of 50% of all Bitcoin mining pool operators. These limitations together suggest that the side-chains protocol, while great for many use cases, will certainly not be ideal for all.
The Promise
If the technical issues around side-chains can be addressed, what is the promise that they bring? Right now, cryptocurrency development can essentially be classified into four quadrants. The first quadrant consists of projects that use the Bitcoin currency and the Bitcoin blockchain – essentially, Bitcoin itself. The second quadrant is protocols that use the Bitcoin blockchain but not the Bitcoin currency; Mastercoin, colored coins and Counterparty are excellent examples of this. The third quadrant uses both an independent currency and an independent blockchain; this contains applications like (to take widely disparate examples) Ripple, Litecoin and NXT. Now, with sidechains the last quadrant has also been filled: using an independent network but using Bitcoin as the underlying currency.
It will be interesting to see what applications that niche works best for. For entire new ecosystems, it’s likely not the right approach; it makes little sense for a completely independent network like Ripple or Ethereum to tie its main internal token to Bitcoin financially and have the two be exposed to each other’s price movements. In the case of such major efforts, it also often makes sense to experiment with different monetary policies; Ethereum’s ether has a linear issuance model that constantly releases a certain fixed number of currency units every year, whereas Ripple released all 100 billion units of XRP to the Ripple organization all at once, and the organization is releasing them over time to developers, investors and people participating in distributed computing projects. For a fork that is intended to serve as a major protocol change, like upgrading from SHA256 to SHA3 or in the case of quantum computers from ECDSA to Lamport signatures or NTRU, it definitely makes total sense. For everything in the middle, it’ll be up to a case-by-case basis to figure out.
In the case of Ethereum, there is a special consideration to keep in mind: Ethereum is a general-purpose cryptographic consensus platform, not a specific “altcoin”. Hence, one can have many different currencies coexisting on the Ethereum platform as contracts; one can have boring old fixed-supply currencies, currencies with a monetary policy managed by a decentralized autonomous organization, currencies which exist to subsidize scientific research or provide a basic income, and even currencies with a built-in two-way-exchange mechanism to act as side-chains. Thus, Ethereum cannot accurately be pigeonholed into either the side-chains quadrant or the Ripple/Litecoin/NXT quadrant; it exists in both.
Indeed, it is very likely that as soon as the Ethereum genesis block launches, there will be side-chains for Bitcoin, Litecoin and Dogecoin implemented as contracts within three months. If side chains can be successfully and securely implemented, this means that Ethereum may even become the preferred means for storing BTC, LTC or DOGE using powerful multisignature storage contracts involving features like withdrawal limits. Between contracts on a general-purpose chain, high-performance special-purpose altcoins, quasi-centralized OpenTransactions servers, side-chins and Bitcoin itself, one thing is becoming clear: cryptocurrencies are going to be able to interoperate like never before.
The post Side Chains: The How, The Challenges and the Potential appeared first on Bitcoin Magazine.
