Through a splash in the media, Purse and its in-house-built alternative Bitcoin implementation Bcoin recently presented their scaling proposal, dubbed “To the Moon.” Where Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited all attempt to increase Bitcoin’s block size limit with a hard fork, and Bitcoin Core developers prefer a Segregated Witness soft fork (SegWit), Purse CEO Andrew Lee announced a third approach: extension blocks.
Extension blocks were actually first proposed by Bitcoin Core developer Johnson Lau in 2013 (as “auxiliary blocks”), and again earlier this year. The solution generally shares many of the virtues of hard forks: extension blocks allow for almost any protocol change. But they share one significant benefit with soft forks: extension blocks are backward compatible.
Well, sort of …
Soft Forks
Soft forks are protocol changes that add new rules or tighten up existing ones. “Old nodes” — as we’ll call them for now — will consider a soft-forked chain valid because it doesn’t break any “old rules.” This makes soft forks backward compatible: they allow old nodes to coexist on the same network with “new nodes” that enforce the soft fork.
While soft forks can only add or tighten rules, they can be cleverly used to extend Bitcoin’s capabilities. To do this, soft forks typically utilize special Bitcoin addresses known as “anyonecanspend.” (They’re actually “outputs,” not addresses, but for simplicity’s sake ignore that for now.)
If these anyonecanspend addresses hold any bitcoins, it means that anyone can spend them; no cryptographic signature or anything else is required … or so it seems to old nodes.
But that’s not what new nodes, enforcing the new rules, see. The new rules prescribe that the bitcoins in these anyonecanspend addresses can only be spent under specific conditions, defined by the soft fork. These new rules can, for example, prescribe that a certain amount of time must have passed (CLTV) or that a signature must be included in a new part of a Bitcoin block (SegWit).
Extension Blocks
Extension blocks resemble soft forks, but quite literally take the concept to another level.
An extension block itself looks a lot like a normal Bitcoin block, which we’ll call a “base block.” Like a base block, an extension block mostly includes a bunch of transactions.
But there is a difference. A base block is cryptographically linked to the previous base block and to the next base block, chaining all base blocks chronologically to form Bitcoin’s blockchain. An extension block, on the other hand, links only to one corresponding base block. Extension blocks “peg along” base blocks.
Similar to most soft forks, extension blocks utilize anyonecanspend addresses. But now, these anyonecanspend addresses act like enter and exit points, to and from the extension blocks.
When a transaction is sent from a base block to an extension block, an old node is tricked. From the perspective of the old node, the coins are sent to a typical anyonecanspend address on the base block. The coins never leave the base block as far as the old node is concerned, and in fact the old node doesn’t even see the extension block.
But from the perspective of a new node, the bitcoins are really sent to a whole new address on the extension block — an “extension address.” This extension address behaves more or less like a normal Bitcoin address.
Interestingly, these bitcoins can then even start to circulate from extension address to extension address, from one extension block to the next. As such, new nodes see the coins moving around and changing ownership. At the same time, old nodes do not see anything and think the bitcoins are still stuck in the original anyonecanspend address.
A new node can also send the bitcoins from their extension address back to a normal address on the base block. This is done by tricking old nodes again: from the perspective of the old node, the coins are finally moved from the anyonecanspend address. Only a new node knows where the coins really came from.
Once the bitcoins are back in the base block and a normal address, old and new nodes see the same thing.
As perhaps the main benefit of extension blocks, they don’t need to adhere to the original Bitcoin protocol in almost any way. This opens up a whole category of new possibilities. The extension blocks can perhaps offer more programmability like Ethereum or Ethereum Classic, or more privacy like Monero, Zcash or Mimblewimble.
Bcoin’s proposal is modest, however: “To the Moon” extension blocks are mostly just bigger than normal blocks (by a so-far unknown amount), so they can handle more transactions. They also include Segregated Witness, and some added benefits specifically crafted to support the lightning network on top of the extension blocks.
Complexity
While extension blocks in general, and To the Moon in particular, can work technically, they do present some drawbacks.
At the heart of these drawbacks, To the Moon is more technically complex than other scaling solutions proposed so far, including all hard forks as well as a Segregated Witness soft fork. This also makes them more complicated to implement.
And from a user perspective, To the Moon would leave old nodes in the dark more than most soft forks do. While old nodes don’t know how coins on soft-forked anyonecanspend addresses can be spent, with extension blocks, old nodes don’t even know where coins are. This means that old nodes can’t trace the history of a coin and perhaps in some cases temporarily can’t even spend it. (This could be the case if a blockchain reorganization takes place; this can cosmetically change what a transaction from an extension block to an old node looks like.)
As such, not everyone loves To the Moon. Johnson Lau, the original proposer of extension blocks, argues that To the Moon “failed to meet the very important requirement of a softfork: backward compatibility.” He instead still considers extension blocks “more as an academic topic than something really ready for production use.” Similarly, Bitcoin Core developer and Bitcoin Knots maintainer Luke Dashjr warns that extension blocks “are a risk of creating two classes of ‘full nodes,’" where non-upgraded nodes are "left insecure like pseudo-SPV (not even real SPV) nodes.” And Bitcoin Core developer Matt Corallo dismisses the idea that extension blocks should be considered opt-in at all — instead “the entire network is forced to trust the extension block,” a “pretty terrible precedent.”
For more discussion on To the Moon, see the Bitcoin-development mailing list.