Litecoin MimbleWimble July update.

With the cryptocurrency market finally breaking a three-year downward trend, confidence in cryptocurrency as a space and technology is returning. With this, we have taken another leap forward towards launching MimbleWimble on the Litecoin network. So, let’s dive into what’s new, and without further ado, let David Burkett, lead developer on the project, share his progress.

The focus this month was initial block downloads. Before I detail what’s going on, I need to provide some background information for those who aren’t familiar with mimblewimble.

Mimblewimble’s biggest innovation is that to verify a chain you only need to know all unspent coins/outputs and a small portion of each transaction called the “kernel”. These two together are called a “chain state”.

In Bitcoin/Litecoin, each block header uses a Merkle tree to commit only the transactions for that block. Since we don’t want to require everyone to download all old mimblewimble blocks or know about all old consumed outputs, we use a different structure to commit transactions. Each mimblewimble header is committed to the root of two different Merkle Mountain Ranges (MMR). One represents all past kernels up to that block, and the other represents all past outputs/coins. Merkle Mountains are another type of tree that supports “pruning.” This means that you can identify the roots of a structure without knowing all of its members (called leaves). To learn more about how this works, please read https://github.com/mimblewimble/grin/blob/master/doc/mmr.md. 3

The initial synchronization process we’ve been working on this month is called ISD (Initial State Download), which is a more accurate term because previous blocks don’t need to be downloaded. To facilitate ISD, I ended up defining the following P2P messages:

• GETMWSTATE — This simply consists of a hash of headers from the recent past. We will call this a “horizontal” header. New node after synchronization maximum One of the standard (non-mimblewimble) blocks in the chain sends this message to a single peer, requesting the state of the mimblewimble chain at the time of that block.

• MWSTATE — Response to the GETMWSTATE message. This contains all chain states required to validate the extended chain up to the horizontal point. Chain state consists of:

• kernels — Represents all kernels in the chain, in order.

• utxos — Indicates in order all output that has not yet been used at the time of the horizon, including the associated bounds proof.

• unspent_bitmap — A compact structure representing the MMR leaf index of the given utxos.

• parent_hashes — Some additional metadata that allows you to determine your MMR root without knowing all of your past consumption output.

Quick note — this design relies on one peer providing a significant amount of data at a time. After release, ideally you would parallelize the sync process using something like https://github.com/jaspervdm/grin-rfcs/blob/pibd/text/0000-parallel_ibd.md 1 or https://github.com/ no see. BeamMW/beam/wiki/UTXO-set,-horizons-and-cut-through 1

All the logic for serializing and deserializing those messages and choosing when to send them has been implemented. We also implemented logic to verify the kernel signature and kernel MMR root.

Unfortunately, we were running out of time this month due to the Grin hardfork, which required a huge amount of effort to support Grin++. As a result, the logic for validating and processing the MWSTATE message could not be completed. In particular, the output root has not yet been verified and the kernel needs to verify that it matches the peggin and pegout of each block. Grin++ is in maintenance mode for the rest of the year, so this will be the last time it disrupts Litecoin progress.

Updated plan:

The original plan was to spend August focusing on reorg logic, but we’re holding off until September. Instead, I’ll focus on finalizing the MWSTATE message handling, cleaning up the code, adding more tests, and maybe even some documentation if I’m feeling really greedy. When developing a project this large, things rarely go exactly as planned, so designs change over time. Using opportunities like this to revisit the code, clean up issues, reevaluate decisions made, etc. will pay dividends in terms of code quality, allowing us to smoothly launch our first testnet at the end of September. wish.