Extension Block Frequently Asked Questions
--
As Extension Blocks have gained more acceptance from the greater community and industry, we’ve outlined below some of the most frequent questions/comments regarding this new improvement to bitcoin, in order to placate any surrounding confusion.
Full specification for Extension Blocks can be found here.
Is Extension Blocks Backwards Compatible?
Yes. Extension blocks are a soft-fork. Every aspect of them still appears valid to the non-upgraded network.
Extension blocks maintain their own UTXO set in order to avoid any interference with the existing bitcoin UTXO set. This is enabled by including a special transaction (the “resolution” transaction) at the end of every main-chain bitcoin block.
Existing bitcoin services will continue to work, uninterrupted by the extension block’s activation, regardless of whether they are watching the extension block or not.
What is the Block Size of the Extension Block? How is the Size Determined?
At the moment, the current extension block size on extnet (the extension block testnet) is a 6mb hard limit, and a 2mb soft limit.
The “soft limit” is calculated by a new metric called transaction “cost”. The cost value itself is determined by the witness program version (script type).
Inside the extension block, every transaction input and output is worth an associated cost: their size weighed against a factor. This factor is determined by the witness program version currently being used. Unknown witness program versions are a factor of 1, whereas currently defined versions are a factor of 8.
In the future, newer witness versions can be defined and assigned to a lower factor. This, in effect, will cause transactions which use newer program versions to consume less space (cost) within the extension block.
The “cost limit” will currently allow for an average case block of roughly 2mb. This concept allows for future soft-fork upgrades from 2mb to a 6mb extension block if or when deemed necessary by the community.
Does it increase miner control in any way?
As described above, miners are able to activate new witness program versions to ultimately increase the extension block’s capacity; however in order to gain the capacity benefits of these new witness programs, economic nodes must begin using them.
In other words, the extension block creates a system in which bitcoin users also have a say in the extension block’s capacity. This allows for the network to scale when needed while hopefully lessening the potential for extended debates.
Does it support Lightning?
Yes. The extension block itself includes a malleability fix in the form of a BIP141-like ruleset (similar to segwit, with a few changes).
The extension block also contains additional security features specifically for Lightning, which when utilized by a lightning payment channel, make successful theft of funds more difficult.
Will wallets support the extension block?
Any wallet which currently supports Segregated Witness is already (mostly) compatible with the extension block. While an extension block could in theory implement a system vastly different from bitcoin as we know it, the current extension block was designed with the easiest upgrade path in mind for wallets and the ecosystem as a whole. As such, it uses the same signature hashing algorithm as Segregated Witness, among other things.
How does the extension block deactivation work?
The extension block was intentionally designed with upgradeability in mind. After the extension block has been successfully activated by the network, an optional deactivation is available.
Deactivation itself is another versionbits (BIP9) deployment with a start time of 3 years from now. In 3 years, miners can vote on whether to deactivate the extension block with the goal of ultimately migrating to a new extension block.
Once the deactivation deployment reaches the “locked-in” state, it remains in that state for 26 retarget intervals (approx. 1 year). During this time, the extension block will still be usable. Once the locked-in period ends, the extension block will cease to be enforced by the network, and the “resolution output” will return to being an anyone-can-spend output.
In reality, future soft-forked code, residing in the same deployment, would be implemented. This code will alter handling of the extension block funds (the resolution output). In order to avoid having to hardfork for the sake of this newer behavior, the rule-relaxing code described above must be implemented now.
With the deactivation deployment in place, funds can be easily migrated to a new extension block if the network ever deems it necessary.
This pre-emptive deactivation code is present to motivate the development of a new (and better) extension block ruleset, and also gives the community ample time to upgrade for such an event.
In Closing
We believe extension blocks are a good solution to the current scaling debate. The design allows us to increase block capacity, improve scalability and add the capability for new functionality; all while utilizing bitcoin’s robust and secure network.
The full spec, testnet information, and faucet for testing Extension Blocks can be found at http://ToTheMoon.org
