Mimblewimble Progress Update Thread

Thanks for the update David :+1:

1 Like

Courage David! It’s almost done

Nice! Great work. Thank you

This is great. I really appreciate your ability to discuss the details of what you’re working on, and your plan to tackle it so clearly and concisely. That’s a rare skill.

Keep trucking David appreciate everything your doing​:raised_hands::raised_hands::raised_hands:

Thanks for the updates and great work!

June Progress:

The existing LTC mempool logic ended up being quite a bit more complex than I predicted, so we’ll need to revisit this area after the testnet launches. For now though, a very minimal implementation supporting MW transactions has been written.

In addition to the mempool changes, code was written to support mining extension blocks, although there are a few edge cases left to handle, and much more testing is needed.

I’ve had concerns about the way we were storing mimblewimble block data in a separate database. It was originally designed this way to be a clean separation from the existing code, in order to facilitate merging future bitcoin commits. Having separate databases is generally a bad idea though, because we lose the ability to make atomic updates, which means the 2 databases could become out of sync. This can lead to a whole host of problems, potentially even ones that are exploitable by remote attackers.

Because of these concerns, I decided to spend some time modifying the code for serializing and deserializing MW blocks & transactions to disk. I was able to take advantage of the groundwork that was laid down as part of the segwit enhancement, to cleanly support serializing the additional data without making major changes to the existing block storage format. As a result, upgraded nodes can successfully save extension block data to disk the same place they’ve always saved blocks, without having to introduce an additional database. A side effect of these changes is that it was relatively straightforward to add support for sharing mimblewimble transactions over the p2p network, which is the first step toward July’s goal of handling MW data as part of the Initial Block Download.

The high-level plan for the rest of the summer remains the same:

July: Initial Block Download

August: Chain reorg logic

September: Activation logic and testnet launch


Outstanding work David, always a treat to here your monthly updates :raised_hands::raised_hands::raised_hands:

1 Like

Eagerly awaiting the next update !!


Same here :slight_smile: ! I am checking this website several times a day :smiley:


July Progress:

The focus this month was on the Initial Block Download. Before I can detail the progress made, I need to give some background info for those not intimately familiar with mimblewimble.

The biggest innovation behind mimblewimble is that, in order to verify the chain, you just need to know all of the unspent coins/outputs, and a small part of each transaction called the “Kernel.” These 2 things together are called the “chain state.”

In bitcoin/litecoin, each block header uses a merkle tree to commit to only the transactions in that block. Since we don’t want to require everyone to download all old mimblewimble blocks, or to know about all old, spent outputs, we use a different structure to commit to the transactions. Each mimblewimble header commits to the root of 2 different Merkle Mountain Ranges(MMRs). One represents all historical kernels up to that block, and the other represents all historical outputs/coins. Merkle Mountain Ranges are a different sort of tree that supports “pruning”, which means we can verify the root of the structure without knowing all of its members (called leaves). For an in-depth look at how this works, I recommend reading https://github.com/mimblewimble/grin/blob/master/doc/mmr.md

Since old blocks don’t need to be downloaded, Initial State Download (ISD) is a more accurate term for the initial sync process that I worked on this month. To facilitate the ISD I ended up defining the following P2P messages:

  • GETMWSTATE - This simply consists of the hash of a header sometime in the recent past. We’ll call this the “horizon” header. A new node, after syncing most of the canonical (non-mimblewimble) blocks in the chain, sends this message to a single peer, requesting the mimblewimble chain state at the time of that block.

  • MWSTATE - The response to a GETMWSTATE message. This contains the entire chain state, which is everything you need to validate the extension chain up to the point of the horizon. The chain state consists of:

    • kernels - All of the kernels in the chain, in order.
    • utxos - All of the outputs that had not yet been spent at the time of the horizon, including their associated rangeproofs, in order.
    • unspent_bitmap - A compact structure that indicates the MMR leaf indices of the provided utxos.
    • parent_hashes - Some additional metadata that allows you to verify the MMR root without knowing all of the past, spent outputs.

Quick sidenote - This design relies on one peer providing quite a bit of data at once. After launch, it would be ideal to parallelize the sync process using something like https://github.com/jaspervdm/grin-rfcs/blob/pibd/text/0000-parallel_ibd.md or https://github.com/BeamMW/beam/wiki/UTXO-set,-horizons-and-cut-through

All of the logic for serializing and deserializing those messages, as well as choosing when to send them has been implemented. I also implemented the logic for verifying the kernel signatures, and the kernel MMR roots.

Unfortunately, I was short on time this month due to a Grin hardfork that ended up requiring an enormous amount of effort to support in Grin++. As a result, I was unable to finish up the logic for validating and processing MWSTATE messages - in particular, the output roots are not yet verified, and I still need to validate that the kernels match up with the pegins and pegouts for each block. Grin++ is now in maintenance mode for the remainder of the year, so this should be the last time it interferes with litecoin progress.

Updated Plan:

The plan was to spend August focusing on reorg logic, but I’m going to delay that until September. Instead, I’m just going to focus on wrapping up the MWSTATE message processing, and focus on cleaning up the code, adding more tests, and maybe even some documentation if I’m feeling really wild. When developing projects this large, things rarely go exactly as planned, so the design changes over time. Having a chance like this to go back through the code and clean things up, re-evaluate decisions made, etc. will really pay off in terms of code quality, hopefully allowing for a smooth first testnet launch at the end of September.


Thanks for the update David. We appreciate all of your hard work. You are making litecoin fungible & this is the last feature needed for a global currency.

We look forward to testing launch next month.

Thank you @masterbtcltc


Keep trucking David, thanks for sharing. I hope all is well on the Grin side. Definitely doing it right and spending extra time to clean things up is the way to go about, it’s the Łitecoin way lol. We appreciate your hard work and honored to have you apart of the ŁTC community :metal::owl::black_heart::boom::boom:. I hope all is well with you and yours on a personal level as we continue life in this altered state as we know it, and look forward to August updates. Cheers.


David, thanks for keeping good work up!


I apologize in advance for the much-briefer-than-usual update. I’ve been busy with tying up loose ends, which are important & necessary, but not very exciting to write about.

August Progress:

As planned, I was able to wrap up the Initial State Download, in particular the validation of the MWSTATE messages. There are still a number of ways where malicious peers can use these new messages to DoS nodes. I’m not yet guarding against all of those attacks, but there will be plenty of time to focus on that after the testnet is released.

I also took advantage of the opportunity to go back and clean up some code & strengthen some of the more fragile logic, particularly around management of the UTXO set (the collection of unspent coins).

Remaining work:

Everything is on track for a testnet release at the end of this month. I’m still figuring out a few final details, but I’ll share more information later this month about what the testnet will look like, and how everyone can get involved. I’m hoping to have a basic CLI or JSON-RPC option for advanced users to experiment with while I transition to focusing on adding non-interactive transaction support.


For those interested, I recently gave a talk about future directions in Mimblewimble which highlighted the weaknesses of vanilla Mimblewimble, and what we can do/are doing to try to solve those. Here’s a recording of the talk: https://www.youtube.com/watch?v=x5vJzp1ehaI&feature=youtu.be


Hi David. Looking forward to watching the YT video.

We appreciate all your hard work on adding scalable fungibility to litecoin.

We look forward to the testnet launch & ultimately the mainnet launch.


can’t wait to try out the cli/rpc


Top notch bro! As usual :metal::owl::black_heart:Ł

Hey @DavidBurkett38

I’ve had this idea. Transferring crypto via wallet is dangerous, by mistaking wallet you lose everything. It is the worst nightmare. Why not use an optional send / receive password which, if incorrect/untyped, sends funds back? #Litecoin


This would be awesome, don’t know if it’s possible tho