Tree Chains vs. Side Chains: The Controversy Explained

Graph of block chain splitting.

If you’ve been paying attention to the Bitcoin scene over the last few months, you’ve probably heard about concepts called “side chains” or “tree chains,” and may even be given to understand that there’s some debate over which of them ought to be added to the Bitcoin protocol. What you probably haven’t heard is a succinct explanation of what they do, why we’d want them, or how they work. Today, we’ll be providing a simple run down about how both of these protocol proposals would operate, and what you, the user, could expect from them.

Why We Care:

The biggest impetus for developing side chains and tree chains is that Bitcoin, as it exists right now, doesn’t scale very well. As the number of transactions increases, the amount of bandwidth and storage needed by each miner is going to balloon to unsustainable levels. We really need some way of splitting up the block chain to reduce the load on individual miners.

Beyond that, it would also be nice if we could integrate some of the features of the altcoin community (like fast transaction verification), without needing to actually deal with altcoins (and the cost of moving money between them via an exchange), or necessarily adopting the tradeoffs of those altcoins into the core Bitcoin block chain.

Side Chains:

In a side chain scheme, you would develop a protocol to allow developers to “link” new side chains to Bitcoin, allowing money to be moved between the main block chain and various side chain and back again. These side chains could have wildly different properties from Bitcoin, including ZeroCoin-style true transaction anonymity, or Dogecoin-style rapid transaction verification. The total amount of Bitcoin value would be unaffected, but you’d be able to move it from side-chain to side-chain, to get the properties you want.

One way to think about this is that side chains allow the creation of altcoins that are “backed” by Bitcoin, in the sense that you can “suspend” Bitcoin, removing it from your wallet, in exchange for an equivalent quantity of the altcoin, and you or someone else can later get those Bitcoins back by proving that they destroyed the corresponding quantity of altcoin.

At first blush, this seems like a great idea. Unfortunately, it has some serious practical drawbacks. By splitting the currency up into many side chains, each side chain has only a fraction of the hashing power of the network as a whole. This is problematic, because in a side-chain scheme, an attacker needs only compromise the weakest side chain. From there, once they’ve completed a 51% attack, they can use that control to create a (fake) longest block chain, create money, and then pass the new coins back into the primary Bitcoin block chain, essentially stealing coins from the pool of frozen coins that back that side chain, creating discrepancies between the main block chain and side chain that are difficult to resolve on a protocol level.

This can happen because side chains don’t share a common block history, meaning that in order to move coins from one to the other, most side-chain proposals simply rely on so-called “SPV proofs,” (the mechanism used by lightweight mobile wallets) which simply check if the money being spent is known to exist in the longest chain and has some number of blocks on top of it (without checking if its history is valid all the way back to the genesis block. These SPV proofs represent a much lower standard of verification than the Bitcoin network is able to enforce internally. A 51% attacker, in a side-chain scheme, wouldn’t just be able to double-spend transactions, they’d also be able to steal from the ‘bank’ of Bitcoins backing the altcoin, and leave the altcoin operating on a fractional reserve basis (a potential disaster in the making).

One possible solution to the increased risk of 51% attack is to use merge-mining to ensure that all of the side chains are mined simultaneously by the same amount of hashing power. In merge mining, since all of the chains use the same hashing algorithm, you attempt to generate a proof of work for both blocks together. You use the hashing power only once, but have the chance to generate a successful proof of work for both chains. At first glance, this seems to neatly resolve the obvious drawback of side chains. Unfortunately, it’s not quite so simple. Merge mining requires the user to run a full node of every currency being merge-mined, which is sufficiently expensive as to dramatically increase the incentive to use mining pools to split up those fixed costs among many miners. This creates a strong incentive towards centralization and is generally a very bad thing. Also, in the event that any side chain does get 51% attacked, the risk of stealing bitcoins in the two-way-peg-scheme remains.

Taken together, these limitations and risks have left many of the core devs skeptical of side chain proposals, although work on them to solve these problems continues.

Tree Chains:

Tree chains are a scheme that is similar to side chains, but attempts to resolve some of the latter’s practical shortcomings. The scheme, as described by Peter Todd, a Bitcoin core dev, is something like this:

Imagine that, instead of having a block chain, we have a tree of chains. The primary Bitcoin block chain that we know and love remains intact, but instead of actually storing transactions, each block stores only two hashes. These are the hashes of two new block chains, which we would denote “left” and “right” – the chains are considered to be the “children” of the main Bitcoin block chain. They would store hashes corresponding to their own children and so on and so forth, to some arbitrary depth at which we reach the “leaves” – block chains in which the blocks store actual transactions.

Transactions would be added to the bottom-most layer of chains at random, based on transaction IDs. Miners would arbitrarily pick from these bottom chains and work on them, a few miners per leaf. At these bottom chains, the rewards and difficulty would be exponentially reduced, allowing miners to verify transactions relatively rapidly (on these subsidiary chains), frequently receiving small rewards. This would smooth out the rate of rewards to miners so much that there would be next to no incentive to pool.

Because these chains form a tree, and each chain is very small, we can do exciting things by letting each chain and its parent be merge-mined together. That means that, by storing the block chain you’re mining, and its parent and its grandparent and so on, a miner can, without storing more than a tiny fraction of the tree (just the path from the root to their active leaf), still merge-mine all the way back to the root, and have the chance to mine blocks and earn rewards at each level. That ensures that the network remains as secure as always: all mining done at each leaf of the tree contributes to the stability of the trunk. Even though transactions in the farthest leaves aren’t particularly secure once they’ve been confirmed (due to the reduced difficulty), as blocks are mined farther up the tree, they grow more secure quickly as information eventually propagates up into the root of the tree and becomes as secure as any normal Bitcoin transaction.

This scheme leaves the integrity of the block chain intact, while allowing a number of advantages. First, it removes the need for every miner to store the entire block chain: they need merely store the path to the leaf that they’re working on at the moment, allowing the entire tree to be securely distributed over many miners. Second, it means that Bitcoin wallets also don’t need to store the entire tree to be fully secure: they can simply store the paths through the tree that correspond to the activity of their wallet: enough information to prove that their money is real (proofs that can be transmitted with a transaction as a sort of signature of authenticity). That means that lightweight mobile wallets can still exist, but with far more security than would be possible using SPV proofs. By allowing the depth of the tree to change with usage, this also allows the Bitcoin network to scale indefinitely and arbitrarily: there will never be a time when the number of transactions is too large for a single miner to handle – they’ll just be split up amongst more leaves.

This proposal is, in some ways, less flexible than side chains, as it does not allow the forks of the block chain to do fundamentally different things than original: it wouldn’t be possible for the individual leaves to implement ZeroCoin-style anonymity, for example, although transaction verification could be made much faster without impacting the security of the network as a whole.

Peter Todd’s solution to this is to open up Bitcoin entirely, by removing the need for miners to verify transactions: miners simply check that the transaction has a fee attached to it, and ignore the contents. Clients would do the verifications themselves, using the tree paths to store the relevant proofs for the Bitcoins that they own, and broadcasting these proofs when they make a transaction.

Thus, it would be possible to use the Bitcoin block tree as a platform for an altcoin: you’d pay your fees in Bitcoin, but the transactions themselves could be anything: you could make ZeroCoin or smart asset transactions on the Bitcoin block chain and benefit from its security. Those using Bitcoin would simply ignore any other altcoin activity as malformed transactions, and vice versa. The metaphor here is a tape recorder, sitting in a room listening to several conversations in several languages. The tape recorder is dumb: it simply records a babble of many voices. However, someone could then later listen to the tape and figure out just what was being said in English. Someone else could then listen to the same tape and figure out just what was being said in Mandarin: one tape benefits both of them, without needing to actually understand anything about what is being said.

Treecoins are a relatively new idea, and have not been entirely vetted by the developer community: there are concerns about how to handle “orphan blocks,” which would be more common in the lowest branches. If your transaction winds up in an orphan-block in an under-mined leaf, what’s your recourse? How do you make sure that your transaction makes it into a new block? There’s also a lot of work to be done to make sure that this new structure doesn’t introduce perverse incentives or unanticipated problems. Finally, the increase in complexity over the traditional Bitcoin system (which has a certain elegant simplicity to it), should be enough to give any cautious developer a moment’s pause. The switch to tree chains would be an enormous shift for Bitcoin, and is a proposal that needs to be seriously worked through before it is declared viable.

That said, many of the properties of a tree chain Bitcoin are exciting, and it seems likely that the future of Bitcoin is going to look very different from the current architecture. To get political for a moment, this sort of dense technical debate reminds us of why attempting to impose broad regulation on Bitcoin prematurely is so foolish: nobody, not even the people building the protocol, know what Bitcoin will look like in a few years’ time, and, even accepting the generous notion of a cautious and well-intentioned regulator, it would be very easy to wind up cumbersome laws that do not make sense, given the transformations that Bitcoin will have undergone.

Further Reading:

To read more about side chains, you can read a detailed white paper proposal here.

To read Peter Todd’s preliminary technical discussion of tree chains, check out his email on the subject on the Bitcoin development mailing list. Alternatively, you can listen to Todd and several other Bitcoin luminaries discuss side and tree chains via the Let’s Talk Bitcoin Podcast.

Technical readers and Bitcoin developers: This was written to the best of my current understanding of these proposals. If I seem to have made any technical gaffes, please let me know in the comments, and I’ll do my best to correct them as quickly as possible.

Update: some phrasing was altered, at Peter Todd’s suggestion, to more accurately reflect the nature of a 51% attack on a side chain.

Image Credit: Theymos via Bitcoin Wiki’s Block chain page (direct image link) (license)