LIP: 2 Layer: Consensus (soft fork) Title: Extension Blocks (Consensus layer) Author: Andrew Yang <[email protected]> David Burkett <[email protected]> Charlie Lee <[email protected]> Comments-Summary: No comments yet. Comments-URI: https://github.com/litecoin/lips/wiki/Comments:LIP-0002 Status: Draft Type: Standards Track Created: 2019-10-20 License: PD
This LIP introduces extension blocks (EB) as a way to implement new protocols to Litecoin without relaxing any consensus rules. Extension blocks are created through peg-in transactions and an integrating transaction, a term coined by Johnson Lau in his original proposal. Litecoin can also be moved out from the EB to the canonical chain through peg-out transactions.
Extension blocks are additional "blocks" of data that each canonical block commits to using an Integrating Transaction (ExtTxn). Like canonical blocks, they shall have their own headers and transactions, though the rules for serializing and verifying extension blocks may differ from those of the canoncial blocks.
EB can be soft forked in. Old clients will only see the coins anchored in the integrating transaction but will not be aware of the EB side.
Our primary motivation behind EB is to implement opt-in Mimblewimble. This is something that is currently not possible through a traditional soft-fork because Mimblewimble is not script-based. However, this is also an opportunity to lay the groundwork to implement alternative proposals using EB as well.
Extension blocks create a side-chain like layer alongside canonical Litecoin blocks in which a miner will commit to the hash of an additional block of transactions. EBs shall define their own rulesets for what constitutes a valid transaction. These EBs must keep their own UTXO sets for use in verifying EB transactions.
Coins can be moved to an extension block using peg-in transactions, which are transactions containing anyone-can-spend segwit outputs with a version and program that indicate that their coins are designated for use on the extension block.
In the canonical chain, we need an integrating transaction for each EB type at the end of every block. If there is only a single EB type, this shall be the last transaction in the block. For each additional EB type added in the future, an additional integrating tx shall be added just before the existing integrating txs.
Finally, coins can also be moved out of the EB through peg-out transactions. The format of these peg-out transactions shall be defined by the EB, and will indicate which address(es) those coins shall be sent to as part of the integrating transaction.
This section will discuss guidelines for creating new types of extension blocks.
The EB designers are free to specify any serialization and verification rules they wish for the extension block and its corresponding transactions, provided that the block or state:
- Contains a form of coinbase transactions to match the canonical chain's peg-in outputs.
- Provides a way for users to send coins out of the EB, and back to the canonical chain.
- Can be committed to with a single hash.
EBs can be used to increase the effective block size of the blockchain. There is no real theoretical limit to the size of these blocks, though it is expected that each EB type will specify some form of consensus rule(s) for limiting its size.
The integrating transaction (ExtTxn) handles both the peg-ins to the EB and the peg-outs from the EB. It consists of X+1 inputs* and Y+1 outputs where X is the number of peg-ins and Y is the number of peg-outs. The first input is always a spend from the previous block’s ExtAddr UTXO and the first output is sending remaining coins to the new ExtAddr for the block (described below).
The integrating transaction must be at the end of the block, as it will be spending outputs created in the same block. For the first activated EB type, it must be the last transaction in the block. The 2nd EB type activated shall require the next-to-last transaction in the block to be its ExtTxn, and so on as more EB types are activated.
- Note that the first ever ExtTxn for an EB type will only have X inputs, as there won’t be a previous block ExtAddr UTXO to spend. If in any block, all the coins are pulled out of the EB, the ExtTxn will still create an output of 0 coins to the ExtAddr. And of course if that happens, the next block’s ExtTxn transaction will spend that output of 0 coins.
A special anyone-can-spend bech32 address will be created every block with the new witness program introduced above. These addresses will be called extension addresses (ExtAddr). For ExtAddr, the witness program, eb_commitment, is 2 to 40 bytes, where eb_commitment commits to the EB corresponding to the canonical block. This ensures that the canonical block commits to the corresponding EB block via the ExtAddr.
At the end of every block, the number of coins held in this block’s ExtAddr will correspond exactly to the number of coins in the EB. As coins move in and out of the EB, the ExtAddr will change every block and will be chained together, with each new ExtTxn spending the previous ExtTxn's ExtAddr UTXO.
For each block, the miner will collect all the transactions sending coins to an _ExtVer_ address (i.e. peg-in transactions), and then spend them immediately in the ExtTxn. The order of the ExtTxn inputs shall match the order of the peg-in transactions in the block.
For each block, the miner will collect all the peg-out transactions in the EB and create corresponding outputs in the ExtTxn, sending coins out on the canonical side. The order of the ExtTxn outputs must match the order of the peg-out transactions in the EB.
Note that it is not possible for a peg-out transaction to send coins to a version ExtVer address. In other words, one cannot peg-out to a peg-in address.
All the fees in the EB will be collected on the canonical side as fees on the ExtTxn. The miner may collect these fees just as they do for canonical transactions today.
A peg-in occurs when coins are sent from the canonical block to the extension block.
A new witness version number (_ExtVer_) will be defined for each EB type. Transactions sent to addresses with version _ExtVer_ will serve as a signal to miners to collect and then spend these peg-in outputs into the ExtTxn (integration transaction).
To execute a peg-in, users send coins to a bech32 address using the new witness program that commits to a corresponding coinbase transaction on the extension block with the same amount of coins. To lock up the corresponding coins on the canonical blockchain, miners will spend these coins in the ExtTxn, sending them to the ExtAddr of the block.
A peg-in transaction on the canonical blockchain will be considered invalid if there doesn’t exist the corresponding coinbase transaction on the extension blockchain. This is to make sure coins aren’t accidentally destroyed.
A peg-out occurs when coins are sent from the extension block to the canonical block.
To execute a peg-out, users will create a peg-out transaction on the EB. This peg-out transaction must commit to a Litecoin address (or script) where the same amount of coins will be sent to on the canonical blockchain. The peg-out transaction in the EB will destroy those coins from the EB side. On the canonical blockchain, the same amount of coins will be sent from the previous block's ExtAddr to the committed Litecoin address (or script) as part of the ExtTxn.
Peg-out outputs on the canonical blockchain must be locked for a number of blocks. This is to ensure that child transactions cannot be created immediately. Since peg-out transactions share similar properties to coinbase transactions in that the transaction hash will change if there’s a reorg, chaining transaction on peg-out transactions would result in invalid transactions after a reorg and lead to potential loss of money.
Extension Blocks function like a soft fork in that older software do not need to upgrade. But non-upgraded nodes i.e. non-EB nodes, will not be able to validate any transactions within the EB. Nevertheless, wallets should treat "anyone-can-spend" scripts with care and non-upgraded nodes are strongly encouraged to upgrade.
It can validate regular Litecoin transactions. It can also validate the amount of LTC peg-in and peg-out of the EB on the canonical side.
It can not validate transactions in the EB. This means it can not validate EB to EB transactions. It also can not validate the EB portion of peg-ins and peg-outs.
It can validate regular Litecoin transactions. It can validate peg-in and peg-out transactions. It can validate EB to EB transactions.
Special thanks to Johnson Lau for originating the idea of extension blocks.
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html
https://eprint.iacr.org/2017/1066.pdf
https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md#specification
This document is placed in the public domain.