<pre>
  LIP: 2
  Layer: Consensus (soft fork)
  Title: Extension Blocks (Consensus layer)
  Author: Andrew Yang <ecurrencyhodler@gmail.com>
	David Burkett <davidburkett38@gmail.com>
	Charlie Lee <coblee@litecoin.org>
  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
</pre>

==Abstract==

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 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013490.html 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.

==Motivation==

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.

==Design==

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.

==Specification==
This section will discuss guidelines for creating new types of extension blocks.

===Extension Block===
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.

====Extension Block Size====
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.

====Integrating Transaction (ExtTxn)====
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.

=====Extension Addresses (ExtAddr)=====
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, <code>eb_commitment</code>, is 2 to 40 bytes, where <code>eb_commitment</code> 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.  

=====ExtTxn Inputs=====
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.

=====ExtTxn Outputs=====
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.

=====ExtTxn Fees=====
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.

===Pegging-In===
A peg-in occurs when coins are sent from the canonical block to the extension block.

====New Witness Program (ExtVer)====
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).

====Workflow====
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.

===Pegging-Out===
A peg-out occurs when coins are sent from the extension block to the canonical block.

====Workflow====
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.

===Backward Compatibility===

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.

====What a non-upgraded, non-EB node can do====

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.

====What a non-upgraded, non-EB node can not do====

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.

====What an upgraded EB node can do====

It can validate regular Litecoin transactions. It can validate peg-in and peg-out transactions. It can validate EB to EB transactions.

==Credits==

Special thanks to Johnson Lau for originating the idea of extension blocks. 

==References==

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

==Copyright==

This document is placed in the public domain.
