Examining Litecoin’s MimbleWimble-Extension Block Proposal
A look at Litecoin’s MimbleWimble upgrade (LIP 0002 and LIP 0003), which will go live on testnet at the end of September.
Introduction
In September, Litecoin’s MimbleWimble implementation will go live on testnet to experiment with this new and interesting protocol which has the potential to enhance the network’s fungibility and scalability, and will be executed via Extension Blocks. MimbleWimble (or MW for short) is a promising protocol since it addresses the missing component in many cryptocurrencies such as bitcoin and litecoin: fungibility.
Observers of these blockchain can easily see the amounts sent/received, change addresses and the entire transaction history. If you’re not careful, your wealth is broadcasted to the world. Or if you’ve received coins from an address associated with criminal activity, your coins become tainted and exchanges/merchants may refuse such coins. Although there are workarounds for privacy in Bitcoin, such as selecting inputs carefully, avoiding address re-use, and so on, fungibility is not yet enforced in the base layer (neither will it be in the near future).
MW builds transactions differently using some clever addition of Elliptic Curve points to ensure that transactions are completely opaque while still permitting validation. Extending this idea to blocks, MW can cut down on the amount of data stored within a distributed ledger enabling greater scaling and faster syncing of new peers.
While the possession of private keys still guarantees the ownership of transaction outputs, the proof of ownership of a private key is no longer achieved by directly signing the transaction. Proof of ownership is instead achieved through methods similar to CoinJoin and Confidential Transactions. Input and output owners form a multi-signature to sign off on each block, eliminating the need for addresses, obfuscating amounts while also scaling much better than existing UTXO-based distributed ledgers (where UTXO stands for Unspent Transaction Ouput).
What is MimbleWimble?
MimbleWimble (MW) is a relatively new protocol that enhances not just privacy but also scalability. The protocol gets its name from J.K. Rowling’s Harry Potter series; MW is a spell (also known as the Tongue-Tying curse) that leaves victims unable to speak and hence perform magic spells.
The protocol’s name is fitting since MW grants plausible deniability to its users, as transactions are more private than UTXO-based blockchains like Bitcoin and Litecoin.
The protocol was released by an anonymous figure (like Bitcoin) called Tom Elvis Jedusor — the name of Voldemort in the French language. Other Harry Potter pseudonyms also made contributions, with Ignotus Peverell (the inventor of the Invisibility Cloak in the Harry Potter series) launching the first implementation of a MW blockchain, Grin.
A brief timeline of the history of the MW protocol is shown below:
A Brief History of MimbleWimble
- August 2, 2016: Tom Elvis Jedusor posts a .onion link to a text file on IRC, titled ‘MimbleWimble’, dated July 19,
- August 2016: Andrew Poelstra and Bryan Bishop verify its just text and rehost the paper. In the following weeks, discussion with other developers led to a positive evaluation of MW and recognition of the protocol’s merit, Andrew Poelstra and Avi Kulkarni developed an extension to improve scaling properties.
- October 8, 2016: Andrew Poelstra releases the paper for Scaling Bitcoin in Milan,
- October 20, 2016: Ignotus Peverell appeared on IRC announcing a project to implement MW, known as Grin,
- March 2017: Ignotus Peverell posted a technical introduction to MW and Grin on GitHub,
- November 2017: The community-based project Grin published its testnet,
- March 2018: Grin’s Testnet2 was released while another MW implementation (BEAM) appeared,
- January 3, 2019: BEAM’s mainnet release,
- January 15, 2019: The first implementation of MW, Grin, launches,
- October 20, 2019: Litecoin Improvement Protocols (LIPs) 0002 and 0003 proposed to add MW to Litecoin via Extension Blocks,
- September 30, 2020: MW with Extension Blocks activate on Litecoin’s testnet.
MW arguably offers a better trade-off between privacy and scalability compared to alternatives such as Confidential Transactions and ZK-STARKs. While providing better privacy, these alternative methods come with the larger transaction sizes so they are not currently as scalable as MW. Therefore, implementing privacy in such a way would greatly increase the growth of the Litecoin blockchain. The privacy guarantees offered by MW are not perfect, but are an improvement on the existing state of UTXO blockchains.
Another desirable feature of MW is that relies on elementary Elliptic Curve Cryptography, which has been tried and tested for decades. It also means that the protocol relies on the same assumptions as Bitcoin does for its security: namely the hardness of the discrete logarithm problem.
The main downsides of MW are that transactions have to be conducted interactively — while doing away with the concept of addresses it requires two parties to interact and to be in communication to transact. Also, script is absent, which means the protocol cannot be implemented as a soft fork and makes MW unusable on Litecoin’s Lightning Network (although work is being done to solve this).
How Does MimbleWimble Work?
As a design for a blockchain-based ledger that is very different to Bitcoin, MW could be implemented as a sidechain or soft forked into Bitcoin as extension blocks in the future. To explain how MW works, let’s first look at how Bitcoin and other UTXO-based ledgers function.
To transact with BTC, inputs create outputs that allow a user to spend funds associated with addresses that they control the private key for. When sending 5 BTC, unless you have an input that is exactly 5 BTC, your wallet will collect enough inputs together to send more, say 7 BTC, and receive change of 2 BTC. All transaction data is publicly verifiable and you can see the inputs used, information on outputs and the amount for a particular transaction on block explorers.
None of this information is hidden and allows for easy verifiability of how much money is in the system. Bitcoin nodes keep track of these unspent outputs to ensure that the consensus rules are not broken, i.e., that no bitcoins can be created out of thin air and no one can spend more than the unpsent outputs that they have ownership of.
For a MW transaction there are also a list of inputs and outputs, but the difference when compared to Bitcoin is that Confidential Transactions (CT) are supported, which encrypts the amount of all transaction data instead of showing them as plaintext. As a result of CT, there are no publicly visible transaction amounts in MW.
CT use a cryptographic primitive called a Pedersen commitment scheme, where only participants in a transaction can see the transaction amount. Instead of verifying the entire UTXO set, the scheme ensures that the sum of the inputs and the sum of the outputs are verifiably equal.
Transactions outputs or inputs can be represented by the following formula:
C = rG+vH
where C is a Pedersen Commitment, G and H are points on the Elliptic Curve, v is a UTXO value, and r is a blinding factor (which takes the role of a secret key to obfuscate the UTXO value). Taken together, rG is the public key.
Others can verify that a transaction is genuine and does not allow anyone to spend more coins than they have ownership of. In simple terms, the Pedersen commitment scheme permits inputs and output amounts being spent remain secret, without impacting the security or verifiability of the blockchain.
For instance, a transaction with two inputs and one output can be represented as follows:
- inputs = (G+2H) + (2G+4H)
- output = (7G+3H)
The transaction is verified and validated by ensuring that (7G + 3H)-(3G + 6H) = 4G - 3H = 0, and as a result we know that no new money was created.
To spend a MW output, you must know the random blinding factor r and the output value v. Only the sender of a transaction knows r and therefore prevents anyone else from spending this output. Rangeproofs are also used to ensure that the total amount of coins does not exceed what is stipulated in the protocol rules. Simply put, rangeproofs are a proof that the output (although encrypted) does not represent a negative value or a value that acts negative when added to other values.
Using CT, all of the encrypted outputs can be summed, the encrypted inputs are subtracted, and we can check that the results sum to zero. A signature is created with a commitment as though it were a public key (this cannot be done with any other value apart from 0). Outputs have Elliptic Curve pubkeys and the difference between the new outputs’ keys and old ones’ is multi-signed by all transacting parties.
As well as inputs and outputs, MW blocks also have kernels which serve two purposes:
- It’s a multi-signature key for all input owners and all output owners, ensuring authentication (i.e., all inputs are signed off on) and to prove non-inflation,
- And it’s also a proof that the transactions add up to zero, i.e. the difference between outputs and inputs is zero.
MW also makes another change to the UTXO model to permit private transactions by integrating CoinJoin to aggregate transactions together in a block. CoinJoin is a privacy-preserving technique where inputs from multiple users are combined to create an anonymity set and then tumbled so that the transaction graph is harder to trace.
By using the transaction history of a transparent blockchain, observers can build a transaction graph, linking transactions together to form insights about the users. To get around this problem, CoinJoin was outlined in 2013 by Bitcoin developer Gregory Maxwell. However, the problem with Bitcoin is that Coinjoin is voluntary and as a result, the anonymity set tends to be small.
However, we can think of MW as enabling CoinJoin by default. One consequence of this is that two valid MW transactions can be concatenated and the result is a valid MW transaction, as shown by Figure 1 below.
When applying to an entire blockchain, all transactions can be combined and the ledger becomes compressed. Every single block is a single transaction, and the block includes the set of inputs, set of outputs, and set of kernels. Data from old blocks can be deleted, in effect reducing the size of the ledger and new participants do not need all of the data. The full transaction content is dropped, but the block headers remain.
Since all inputs come from old outputs, every single input and every spent output can disappear. Since the sum of inputs minus the sum of outputs equals to the kernel, we can delete the inputs and outputs that are the same. The kernel is an aggregate transaction authenticated by everyone involved in the two transactions shown in Figures 1 and 2. Inputs and outputs can then be cancelled out algebraically to remove the intermediary steps, as shown by Figure 2 below.
The only data that is needed to verify the blockchain is the chain of headers, the list of unspent outputs from each block and the kernels/signatures — which amounts to a lot less data than downloading all of the chain (every single transaction that ever occurred is contained within the kernels).
As a result, the rate of growth of a MW blockchain is not proportional to the total length of the historic chain (as it is with Bitcoin), but instead is proportional to the number of UTXO’s. Another consequence is that when a transaction spends a number of outputs but creates fewer outputs, the size of the blockchain will actually shrink from the perspective of a new verifier.
For a new verifier of the Bitcoin blockchain, they have to download all blocks and play forward each on-chain transaction that ever occured. This involves downloading more than 330GB of data (known as an initial block download) to verify the ledger — which includes all of the signatures and every transaction that has ever occured to determine the state of the chain.
As compared to MW, it makes running a Bitcoin node more difficult/expensive, disincentivising participation. A new participant in a MW ledger can download all transactions and combine them together. Every single input, except coinbase inputs which create new coins, are not required to be verified (since every input is an output of a previous transaction).
Everything in the blockchain goes away apart from:
- Coinbase inputs: a fixed amount of coins per blocks which are added to the existing supply,
- Unspent outputs: where the unspent output set gives us the final system state, and
- Kernels.
So far, we’ve seen how MW ledgers differ from the UTXO model to provide more privacy and better efficiency. The specifications of the MW that will be used by Litecoin are detailed in LIP 0003. But Litecoin will not replace the UTXO blockchain with this new protocol. How exactly the protocol will be implemented is explained by LIP 0002, namely via Extension Blocks, which we detail below.
What are Extension Blocks?
Extension Blocks (EBs) were proposed by Johnson Lau in 2017 as a way of having funds enter and exit an additional block using special opcodes, which built on Lau’s prior proposal in 2013 (known as Auxiliary blocks).
The purpose of EBs is to enable new protocols within a blockchain network without changing the consensus rules. In particular, EBs will allow Litecoin to implement MW without re-architecturing the legacy, UTXO-based chain. Since the MW protocol is not script based, a soft fork would not be possible.
Instead it will operate as a sidechain-like layer alongside legacy blocks, and miners will commit to the Merkle root of an additional block of transactions. MW blocks will run alongside the legacy chain at the same frequency of 2.5 minutes, on average.
Therefore, MW transactions provide Litecoin users with opt-in privacy; you can choose whether to use the transparent legacy chain or the MW layer which provides stronger privacy guarantees. Once activated on mainnet, users will be able to move their legacy LTC to the MW layer through peg-in transactions to take advantage of the enhanced fungibility and scalability.
Peg-in Transactions
Peg-in transactions refers to coins moved from the legacy blocks to EBs, which must keep their own UTXO set. In the legacy chain, an integrating transaction is required at the end of each block.
For peg-in transactions, inputs in a legacy block either turn out as outputs in a legacy block or can be sent to a bech32 address that contains the amount and commitment of the corresponding kernel on the MW side.
In the integrating transaction, the miner will send the peg-in coins to a Hogwarts address (HogAddr for short, which is another name for an Extension Address) which doubles to a commitment to the EB header.
To prevent miners from assigning coins to an unintended recipient (remember, MW protocol does not have the concept of addresses), the MW coinbase transaction kernel commitment is encoded into the bech32 address. As a result, the peg-in transaction can be verified in the legacy Litecoin blockchain.
All the fees in the MW EB will be collected on the legacy chain as fees on the HogEx transaction.
Now we’ve seen how peg-in transactions work, let’s look at how moving coins from the MW layer to the main, UTXO-based chain works.
Peg-out Transactions
LTC can be moved out of EBs through peg-out transactions. This is done by creating a MW transaction containing a peg-out kernel indicating the amount to peg out and the address to send the coins to. The pegged-out coins are then sent to the LTC address as part of the integrating transaction.
For peg-out transactions, coins in the EB must be destroyed and then sent out of the HogAddr. Litecoin’s 84 million coin limit cannot be breached, as for every LTC that is pegged into the MW layer, it must be destroyed to move back to the legacy chain. Any hidden inflation will be confined to the MW-EBs and could risk a different exchange rate for coins on either side, although exchanges are not required to support MW-LTC coins.
The recipient’s Litecoin address will be stored in the kernel of the MW peg-out transaction. This way, peg-out addresses on the legacy side can be matched and verified with the Litecoin address in the MW kernels in the EB.
Peg-out outputs on the legacy blockchain must be locked for six blocks (approximately 15 minutes on average). More research is required to determine the optimal lock time, as well as the block size for EBs.
EBs function like a soft fork in that older software do not need to upgrade. But non-upgraded nodes will not be able to validate any transactions within the EB.
In short, only upgraded MW nodes can validate regular litecoin transactions, peg-in and peg-out transactions, as well as MW transactions within extension blocks. Non-upgraded nodes can only validate regular LTC transactions and the amount of LTC pegged in and pegged out of the extension blocks on the legacy side.
Conclusion
Litecoin’s move to incorporate MimbleWimble through Extension Blocks is a major departure from Bitcoin and could possibly help differentiate it from the top altcoins by working towards achieving a key property of money missing from most cryptocurrencies: fungibility.
The benefits are clear for LTC users; increased privacy, and better efficiency that reduces the costs of running a node (the size of the chain and the time required to verify the chain). Since the MW-EBs provide opt-in privacy, most activity may remain on the legacy, transparent chain for a while. As we’ve seen with SegWit, adoption by the ecosystem takes time. Both LIP 0002 and LIP 0003 will be activated by BIP8, where miners will be able to activate it early with a 75% signaling threshold.
There are also benefits for Bitcoin. Since the design of MW is so radically different, because Extension Blocks are not yet “battle tested” and given Bitcoin’s conservatism with regards to protocol updates, Litecoin’s experimentation with the MW protocol could help inform how and when to incorporate Confidential Transactions (or MW) into Bitcoin.
*Previously the article stated that Beam launched on January 17, 2019. This has been updated with the correct date of January 3, 2019.
About Interdax:
Interdax — level up your trading with the next-gen digital asset derivatives exchange.
