{"id":23999,"date":"2017-04-20T17:21:42","date_gmt":"2017-04-20T17:21:42","guid":{"rendered":"http:\/\/ci027cfe6b00042697"},"modified":"2017-04-20T17:21:42","modified_gmt":"2017-04-20T17:21:42","slug":"how-extension-blocks-are-backward-compatible-and-how-theyre-not","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/how-extension-blocks-are-backward-compatible-and-how-theyre-not","title":{"rendered":"How Bitcoin Extension Blocks Are Backward Compatible \u2014 and How They\u2019re Not"},"content":{"rendered":"
<\/div>
<\/figure>\n

Through a splash in the media, Purse<\/a> and its in-house-built alternative Bitcoin implementation Bcoin<\/a> recently presented their scaling proposal, dubbed \u201cTo the Moon<\/a>.\u201d Where Bitcoin XT<\/a>, Bitcoin Classic<\/a> and Bitcoin Unlimited<\/a> all attempt to increase Bitcoin\u2019s block size limit with a hard fork, and Bitcoin Core<\/a> developers prefer<\/a> a Segregated<\/a> Witness<\/a> soft fork<\/a> (SegWit), Purse CEO Andrew Lee announced<\/a> a third approach: extension blocks.<\/p>\n

Extension blocks were actually first proposed by Bitcoin Core developer Johnson Lau in 2013<\/a> (as \u201cauxiliary blocks\u201d), and again earlier this year<\/a>. 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.<\/p>\n

Well, sort of \u2026<\/p>\n

Soft Forks<\/strong><\/p>\n

Soft forks are protocol changes that add new rules or tighten up existing ones. \u201cOld nodes\u201d \u2014 as we\u2019ll call them for now \u2014 will consider a soft-forked chain valid because it doesn\u2019t break any \u201cold rules.\u201d This makes soft forks backward compatible: they allow old nodes to coexist on the same network with \u201cnew nodes\u201d that enforce the soft fork.<\/p>\n

While soft forks can only add or tighten rules, they can be cleverly used to extend Bitcoin\u2019s capabilities. To do this, soft forks typically utilize special Bitcoin addresses known as \u201canyonecanspend.\u201d (They\u2019re actually \u201coutputs,\u201d not addresses, but for simplicity\u2019s sake ignore that for now.)<\/p>\n

If these anyonecanspend addresses hold any bitcoins, it means that anyone can spend them; no cryptographic signature or anything else is required \u2026 or so it seems to old nodes.<\/p>\n

But that\u2019s 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<\/a>) or that a signature must be included in a new part of a Bitcoin block (SegWit).<\/p>\n

Extension Blocks<\/strong><\/p>\n

Extension blocks resemble soft forks, but quite literally take the concept to another level.<\/p>\n

An extension block itself looks a lot like a normal Bitcoin block, which we\u2019ll call a \u201cbase block.\u201d Like a base block, an extension block mostly includes a bunch of transactions. <\/p>\n

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\u2019s blockchain. An extension block, on the other hand, links only to one corresponding base block. Extension blocks \u201cpeg along\u201d base blocks.<\/p>\n

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.<\/p>\n

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\u2019t even see the extension block.<\/p>\n

But from the perspective of a new node, the bitcoins are really sent to a whole new address on the extension block \u2014 an \u201cextension address.\u201d This extension address behaves more or less like a normal Bitcoin address.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Once the bitcoins are back in the base block and a normal address, old and new nodes see the same thing.<\/p>\n

As perhaps the main benefit of extension blocks, they don\u2019t 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<\/a> or Ethereum Classic<\/a>, or more privacy like Monero<\/a>, Zcash<\/a> or Mimblewimble<\/a>.<\/p>\n

Bcoin\u2019s proposal is modest, however: \u201cTo the Moon\u201d 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<\/a> lightning<\/a> network<\/a> on top of the extension blocks.<\/p>\n

Complexity<\/strong><\/p>\n

While extension blocks in general, and To the Moon in particular, can work technically, they do present some drawbacks.<\/p>\n

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.<\/p>\n

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\u2019t know how coins on soft-forked anyonecanspend addresses can be spent, with extension blocks, old nodes don\u2019t even know where coins are. This means that old nodes can\u2019t trace the history of a coin and perhaps in some cases temporarily can\u2019t 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.)<\/p>\n

As such, not everyone loves To the Moon. Johnson Lau, the original proposer of extension blocks, argues<\/a> that To the Moon \u201cfailed to meet the very important requirement of a softfork: backward compatibility.\u201d He instead still considers extension blocks \u201cmore as an academic topic than something really ready for production use.\u201d Similarly, Bitcoin Core developer and Bitcoin Knots<\/a> maintainer Luke Dashjr warns<\/a> that extension blocks \u201care a risk of creating two classes of \u2018full nodes,\u2019” where non-upgraded nodes are “left insecure like pseudo-SPV (not even real SPV) nodes.\u201d And Bitcoin Core developer Matt Corallo dismisses<\/a> the idea that extension blocks should be considered opt-in at all \u2014 instead \u201cthe entire network is forced to trust the extension block,\u201d a \u201cpretty terrible precedent.\u201d<\/p>\n

For more discussion on To the Moon, see the Bitcoin-development mailing list<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Through a splash in the media, Purse and its in-house-built alternative Bitcoin implementation Bcoin recently presented their scaling proposal, dubbed \u201cTo the Moon.\u201d Where Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited all attempt to increase Bitcoin\u2019s block size limit with a hard fork, and Bitcoin Core developers prefer a Segregated Witness soft fork (SegWit), Purse […]<\/p>\n","protected":false},"author":2509,"featured_media":24000,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[1662,2306,1079],"class_list":{"0":"post-23999","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-block-size","9":"tag-forks","10":"tag-segwit"},"author_data":{"id":2509,"name":"Aaron van Wirdum","nicename":"aaron-van-wirdum","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/aaron-van-wirdum-96x96.jpg"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/how-bitcoin-extension-blocks-are-backward-compatible-and-how-theyre-not.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/23999","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/2509"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=23999"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/23999\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/24000"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=23999"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=23999"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=23999"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}