About extension blocks: increasing the max block size via a (fairly) simple softfork

Ticker

1 BTC = $39677.85 USD  (via Coinbase)
1 ETH = $2285.66 USD  (via Coinbase)
1 LTC = $135.25 USD  (via Coinbase)
Quotes delayed up to 2 minutes.

Kryptous

Crypto Coins News - Ratings - Reviews

1 News - 247 News - 247 Bitcoin - 1 Search

BTC - BCH - ETH - LITE - XRP

Buy Sell Trade Crypto Here

 

For the benefit of those who are not familiar with the idea, I'd like to explain an idea called extension blocks, which is a pretty simple way of increasing the max block size via a softfork. Like some of my past posts (see [1], [2]), this is a very old idea that is well-known to experts, but not as well-known to the wider community because experts find it boring and sub-optimal, and so don't talk about it much. But I think that there's often value in considering ideas that are sub-optimal but simpler: sometimes, perfect is the enemy of good.

SegWit is a special type of extension block softfork, so I'm certainly not suggesting here that an extension block softfork be done instead of SegWit, but maybe it would be appropriate sometime in the future.

Here's how it works:

After the softfork activates, miners are required to include within their old-style blocks the hash of the header of an additional extension block. The extension block will have no PoW of its own, and the extension block header will probably just be a transaction count and an additional Merkle root for a bunch of additional transactions. The extension block hash needs to be connected to the old-style block header, so it'll probably go into the coinbase transaction.

Transactions with a version number >= some number are new-style transactions, and must go into the extension block. Transactions with a version less than that are old-style transactions, and must go into the old-style block.

The 1MB block-size limit continues to apply to the old-style block. An additional larger limit is added which applies to the total size of the old-style block plus the extension block. New full nodes download the old-style block and the extension block for each block, and process all of those transactions pretty much equally. Old nodes continue to download and verify only the old-style blocks, which remain valid under the old rules.

New nodes will produce new-style addresses with a new address version, and can also produce old-style addresses

If you want to convert from an old wallet to a new wallet, no special transactions are necessary. After upgrading your wallet software, from now on you'll just send transactions with the new transaction version. It's not a problem that some of the UTXOs being spent are in old-style blocks, since all new nodes have those blocks. Old nodes will think that the UTXOs you're spending are remaining perpetually unspent.

There are four transaction cases:

  • Old wallet to old wallet: The same type of transaction as today. It must go into the old-style block. It works the same as before.
  • New wallet to new wallet: A normal transaction with the new transaction version. It must go into the extension block.
  • Old wallet to new wallet: If the user of the new wallet desires compatibility, he will publish both a new address and an old address. The old wallet will send to the old address. The new wallet downloads all old-style blocks, so has no problem accepting this transaction.
  • New wallet to old wallet: Not possible in the simplest type of extension block softfork. (But it can be made possible if desired, as I'll explain below.)

So old wallets can keep operating without interruption for as long as there exists a group of people who want to do so. Probably 100{88c91daedd271a990a10650c05d769cae2765e0603edf30ca95f18704e5748e8} of transactions will move to extension blocks eventually, since there isn't really any advantage to using old-style transactions, but there's no rush. If desired, after 5 years or something when literally no one is using old wallets anymore, a hardfork could remove old-style blocks in order to simplify the network a little, transferring old-style UTXOs so that no coins are destroyed in the process. (Anyone with a wallet still sitting in cold storage would just have to import their wallet into new software.) But this hardfork is never required.

The only issues for old wallets are that they'd eventually find it difficult to receive transactions, and they would also be even less able to trust 0-conf transactions: A transaction spending an old-block UTXO using an extension block will not be seen by old nodes, so any future double-spend of that UTXO will be seen as valid by old nodes, but is actually invalid and will never be confirmed.

There's no problem with doing extension-block softforks multiple times. You can have multiple extension block "layers" live at the same time.

It is possible to allow transactions from new wallets to old wallets, but this makes the softfork more complex. I tend to think that if extension blocks are to be done, then it's better to keep it simple, since 99{88c91daedd271a990a10650c05d769cae2765e0603edf30ca95f18704e5748e8} of people are going to upgrade quickly anyway.

To prevent a situation in which the first users of upgraded wallets are unable to spend their BTC in most places, new addresses could initially do nothing special, resulting in the same old-style transactions. Once it's observed that new addresses are quite prevalent, wallet software could be changed to actually make use of extension blocks. The actual softfork would occur beforehand — how addresses are handled is merely a software change, and need not be exactly coordinated.

But if desired, you can allow new-to-old transactions in either of these two ways:

Method 1: New wallets will show two balances, an old balance and a new balance. You can automatically convert from old to new as I described previously, but converting from new to old requires trading coins on a market, probably for worse than a 1-to-1 ratio. Sending to an old address draws on your old balance, while sending to a new address draws on your new balance. Users can figure out how to move funds between the two accounts and deal with their constraints. In practice, people would probably want to keep most of their BTC on the old side until actually needed for transactions, since BTC there would be slightly more valuable. After a while, the desire for old BTC would fade away enough that people would feel more comfortable converting all of their BTC. To simplify wallet GUIs, wallets could by default retain the current single-account mode unless they actually contain old BTC or the user changes the settings, in which case they would use the more difficult two-account mode.

Method 2: You can add sidechain-style 2-way peg. Instead of simply spending old UTXOs via new-style transactions, you have to first spend the old UTXO via an old-style transaction which sends the BTC to a specially-formed output which old nodes see as anyone-can-spend but new nodes see as a different scriptPubKey specified by the sender, spendable in extension blocks. If you have only new-style UTXOs and want to send BTC to an old wallet, you send a special new-style transaction which destroys the BTC on the new side but permits you to spend an appropriate portion of the old-style anyone-can-spend UTXOs created by others. Only "deposits" into the extension block system can be "withdrawn" again later into the legacy system, like a sidechain. The rules will be verified by all new full nodes, so there is no loss in security.

The reasons that extension blocks are not popular among Bitcoin experts are:

  • Dealing with the the issue of new-to-old transactions is messy and difficult, and especially if you want 2-way-peg, full sidechain support is probably strictly superior.
  • It is a max block size increase, which often isn't the real answer to scaling. The max block size is like the "maximum capacity" sign on an airplane, while the system's scalability is like how much weight the airplane can actually hold without crashing. Just replacing the sign isn't what you need, and could lead to disaster.
  • A hardfork max block size increase would require a lot less code and complexity, especially from the perspective of lightweight nodes. (Note that the addition of what is essentially an extension block is a necessary part of SegWit's malleability fix, so SegWit wouldn't be noticeably simpler/smaller as a hardfork.)

But let's say that someday the system's real scalability increases dramatically due to block-storage sharding, compacted transactions, TXO commitments, etc., and it's widely agreed that the max block size can safely be doubled. Then the simple extension blocks softfork is something that could be done very quickly, without any of the more complicated sidechain stuff, with a high degree of backward-compatibility, and without the issues associated with hardforks. So it's something worth thinking about.

submitted by /u/theymos
[link] [comments]

Kryptous

Crypto Coins News - Ratings - Reviews

1 News - 247 News - 247 Bitcoin - 1 Search

BTC - BCH - ETH - LITE - XRP

Buy Sell Trade Crypto Here

 

Ticker

1 BTC = $39677.85 USD  (via Coinbase)
1 ETH = $2285.66 USD  (via Coinbase)
1 LTC = $135.25 USD  (via Coinbase)
Quotes delayed up to 2 minutes.

Leave a Reply