How will MimbleWimble work on Litecoin?
You may have looked at the title of this piece and thought I’d gone slightly crazy, or that I’d decided to do a left field piece about Harry Potter spells. If you thought the later you’re actually a little closer, because this is an upgrade coming to the Litecoin network and it is in fact named after a Harry Potter spell!
MimbleWimble is a privacy and scalability upgrade which was first deployed on the Grin network in January 2019 and is now planned for activation on the Litecoin network within the upcoming v0.21.X release (included in this upgrade is also Taproot for Litecoin). It’s named after a tongue tying spell in Harry Potter which stops you revealing secrets.
Let’s unpack what this upgrade is looking to bring to the Litecoin network and how it works under the hood …
Once Upon A Time ….
A developer under the pen name Tom Elvis Jedusor (the French version of Voldemort) published the MimbleWimble paper on the IRC channel #bitcoin-wizards in July 2016. This garnered some attention and was soon picked up by well know bitcoiner and cryptographer Andrew Poelstra who released a ‘refined’ version in October 2016. Shortly after this, another Harry Potter inspired pseudonymous developer Ignotus Peverell (the original owner of the invisibility cloak) posted a partial implementation as a github project: ignopeverell/grin. This project was named Grin and the testnet launched in Nov 2017.
Following contributions by many other Harry Potter characters including wand maker Garrick Ollivander, Gryffindor student Seamus Finnigan, weeping ghost Moaning Myrtle and many more, the Grin mainnet launched in November 2019 and has now seen over 3m transactions processed. However Grin wasn’t the only implementation of MimbleWimble — the Beam blockchain launched in March 2018 and has now seen almost 6m transactions processed. For in depth analysis of the Grin vs Beam implementation I’d recommend this piece: https://hackernoon.com/grin-mimblewimble-bitcoin-cryptocurrency-1f6702cdf7eb
There remained questions about whether the technology would be brought to other chains, like Bitcoin, in order to help boost privacy. However Bitcoin Core developer Peter Wuille had already outlined some of the challenges in a 2016 podcast (and even neatly predicted some of the details for the Litecoin implementation which would follow 6 years later);
Introducing mimblewimble into bitcoin in a backwards-compatible way would be a difficult exercise. It may not be impossible, but it would be hard. I think the way if people were experimenting with this, I would expect it to be an experimental separate chain or sidechain. In a sidechain we would not introduce a new cryptocurrency but it would be a separate chain.
But what even is MimbleWimble ….
The Magic Explained
To understand this we first need to revisit the design of the Bitcoin blockchain and take a look at a transaction (n.b this holds for Litecoin transactions too):
We can see that this transaction has two inputs and three outputs, and we can see how much is associated with each address. Whilst we don’t know (without the help of blockchain analytics tools such as Elliptic) who owns these addresses, that’s still quite a bit of information we can use for well known data analytics techniques such as; common spend clustering (the grouping of input addresses) and change prediction (identifying any output addresses which belong to the sender).
As such, the transparency of transactions on the Bitcoin blockchain allows for any node on the network to help validate and process transactions but also reveals quite a lot of information.
The question is then; can we still have a decentralised network where any participant can validate and process transaction but without this information leakage? The answer is of course yes and there are many privacy orientated blockchains which exist today — two of the most well known are Zcash and Monero.
However these are independent blockchains with their own native assets and privacy features built in from the outset. So another approach was required for transparent assets, such as bitcoin and litecoin, which did not have privacy as a foundational design element but may want a more privacy enhancing approach going forward.
N.b there is a section of the Bitcoin whitepaper where Satoshi talks about privacy but this is mainly around not reusing addresses or revealing public keys too widely.
In addition to this privacy challenge, when a new node on the Bitcoin (or Litecoin) network starts up, it must sync a complete history of every transaction on the network, or more accurately, every Unspent Transaction Output (the ‘coins’ created and destroyed with each transaction). This can take many hour or days to sync and requires an increasing amount of memory, so raises questions about scalability and sustainability to attract new nodes to the network.
Enter MimbleWimble — a privacy enhancing approach which can be deployed as an independent blockchain (as with Grin or Beam) but also as an upgrade to existing blockchains such as Litecoin, and which carries the benefit of reducing the data set a new node needs to sync with in order to start validating transactions.
The Litecoin Implementation
The Litecoin implementation for MimbleWimble includes three components; Transaction Kernels, Transaction Cut-Through and Extension Blocks.
Extension Blocks
The first notable implementation detail, and as predicted by Peter Wuille in his 2016 podcast recording, is that MimbleWimble is being included as a sidechain to the existing Litecoin network. This means that there will be a ‘parallel highway’ of blocks (called Extension Blocks) which are created with the same cadence to blocks on the Litecoin network (every c2.5 mins) and users can enhance the privacy of their Litecoin transactions by sending funds into and out from this parallel chain. Miners will then commit a merkle root (a summary of all transactions from the Extension Block) on the main Litecoin chain.
This approach allows for transparent main chain transaction and privacy enhanced Extension Block transactions to co-exist, and is completely opt-in for users.
Sending and Removing Funds From Extension Blocks
(To avoid you having to scroll back up to refer to this diagram, I’ll repost it as we move through the explanation)
To send funds into an Extension Block (EB), users first create pegging-in transaction where LTC are sent to a special address type ( A in the above diagram) which makes use of transaction kernels. For simplicity in understanding, it’s best to imagine this as as an ltc1 prefix address which contains an extra piece of information that can link it to a specific EB ( F in the above example). In reality it’s a little different but we’ll save some brain space on this because there’s plenty more to dig into …
These pegging-in transactions create a pool of funds ready to be transacted in the specific EB.
To remove funds from an EB the user must create a pegging-out transaction within which they specify the address they want to receive the LTC on the main chain and a link to the amount from the extension block ( G in the above diagram). This creates a queue of ‘withdrawal requests’.
To process the pegging-in and pegging-out transactions, the miner creates a special type of transaction called an Integration Transaction (now also known as a Hogwarts Transaction) which has X+1 inputs and Y+1 outputs, where X and Y are the number of pegging-in and pegging-out transactions. In the diagram there’s only one pegging-in and one pegging-out transaction so it’s a little simplified.
Integration Transaction Inputs
The first input in the Integration transaction will always be a spend from the previous block’s HogAddr ( the grey box in the HogEx within the diagram above) to the current block’s HogAddr ( C in the diagram above). This ensures any coins which were left within the previous EB are ‘moved’ into this new EB. The remaining inputs then match the pegging-in transactions for the EB ( B in the above diagram).
The miner will then create MimbleWimble coinbase transactions which send the coins from the pegging-in transaction ( B in the diagram above) to the HogAdd ( C in the above diagram). This tops up the existing EB ‘balance’ moved from the previous HogAddr with the new pegged in coins. Unlike blocks on the main chain, there will be one coinbase MW per pegging in transaction to the extension block therefore 10 pegging-in transaction will result in 10 MW coinbase transactions to the EB.
Integration Transaction Outputs
The first output in each HogEx will be to the new HogAddr for the EB ( C in the diagram) and matches the first input which is moving any remaining ‘balance’ from the last EB to the new EB. The remaining outputs are processing the pegging out transactions and therefore sending a corresponding amount of LTC to the specified withdrawal LTC addresses from the pegging-out transactions ( D in the diagram). It’s worth noting that the pegged out funds are currently locked on the Litecoin blockchain for 6 blocks in order to provide some additional security for onwards spending. However this confirmation cap will likely be reviewed once there is data after the activation.
As outlined above, LTC can be moved into or out from extension blocks, however where the privacy preserving magic happens is within these extension blocks. That’s because anyone can collaborate to create MimbleWimble transactions within the EBs using the LTC they have pegged in from the main chain. These MW transactions are similar to Bitcoin Lightning Network transactions in that they are not stored on the main chain. As such Alice could peg over 10 LTC from the main chain, conduct 50 MW transactions to various other participants and only the ‘summary’ the activity is committed back to the main chain e.g she now has 3 LTC.
There’s an awful lot of exciting maths going on under the hood with MimbleWimble so I’ll break that down in a future piece however for now it’s sufficient to say that using MWEBs on Litecoin will allow for private transactions moving LTC and provide optional confidentiality for users of this blockchain.
Transaction Cut-Throughs
In addition to the privacy element of WM, there is also a scalability benefit. When a new Litecoin node is synced for the first time, it must process the entire history of the blockchain in order to validate LTC transactions. However for MimbleWimble transactions, using transaction cut-throughs will mean that only the UTXO set is required for verification. This will greatly decrease the time to sync.
For example, if there are two identical transactions from A to B and then B to C, then the history of the intermediary transactions can be “cut” resulting in a merged transaction from A to C. In this way, only the current UTXO state is needed and there is no need to store any addresses in the blockchain. (LIP-003)
As such, using transaction cut throughs will reduce the amount of data a new node needs to sync therefore reducing the time to become active and will reduce the ongoing storage costs making it less costly to maintain a full node.
Wen upgrade?
So this all sounds incredibly exciting and beneficial for those who care about node scalability and transaction privacy but when is this coming?
As noted by the Litecoin OG himself the MimbleWimble Extension Block upgrade will only activate if 75% of nodes signal for it or if the 1 year time limit is reached.
Currently signalling for the upgrade is lower than expected at less than 10% so is not looking likely in the near future, however the accompanying Taproot upgrade is fairing better at around 20%.
Current discussions seem to pinpoint the low uptake as miner inertia since the hard stop activation is still c7 months away and with many waiting for Litecoin core v0.21.2 to be released first. As there’s no timelines on this next version, and with one Litecoin developer simply saying “ When it’s ready :)” the MWEB and Taproot upgrades look to be just out of reach for now.
You can monitor the progress towards activation here: https://litecoinsignals.quest/#stats
Originally published at https://www.linkedin.com.
