This update was written and provided by Litecoin MimbleWimble lead developer David Burkett.
——–
Documentation
I’ve spent some time documenting all of the code changes to assist our auditors. For those interested, this is the current list of technical documents describing the MWEB changes (several are only partially complete):
LIP-0002 – This describes the process for adding extension blocks to LTC, including describing how pegging-in, pegging-out, and integrating transactions work
LIP-0003 3 – This is our original design for Mimblewimble extension blocks. It’s a bit outdated, but should provide a high level understanding of how it works.
LIP-0004 – This describes our approach to supporting one-sided txs, instead of relying on interactive transactions like traditional Mimblewimble
LIP-0005 – I’m still filling in missing data structures here, but this documents the P2P protocol changes and describes how MWEB transactions and blocks are serialized
Consensus Rules 1 – Not a comprehensive list, but describes the most important consensus rules
Kernels – Describes how kernels are serialized, the various features that are supported (e.g. lock height), and how new features can be soft forked in later on.
Data storage – Describes the new database tables and data files that were added
Stealth addresses – How stealth addresses are generated, how we support subaddresses, how addresses are serialized, etc.
Pruned Sync 1 – Describes how pruned sync will be supported in future releases
Coding & Testing
I performed my own review of all of the node logic to look for ways to improve security and performance, which resulted in a number of improvements to the code & design:
Kernel MMR is now per block, instead of a perpetually growing MMR. It was determined that we don’t gain much by having a cumulative kernel MMR, so switching to a per-block MMR means less time spent hashing, and a lot less disk space needed to store the MMR.
Switched from sha256 to the much-faster blake3 for all MWEB hashes.
New stealth address format that’s more consistent with previous address types, along with having better error detection.
More compact serialization formats for all MWEB data structures which will result in less disk space usage, less data transferred between peers, and therefore slightly higher throughput.
Better test coverage
Audits and Reviews
I’ve officially handed off the final code changes and documentation to Quarkslab, so we should have a more detailed timeline from them any day now.
I’ve created a new code review 5 with the most critical changes to the litecoin consensus code. It’s much smaller and more focused than the libmw review from a few months ago, so hopefully we will get more reviewers and faster feedback from other devs.
I’ve made slight changes to the estimated timeline on wenmweb.com 23, but overall, we’re still working toward MWEB activation at the end of the year.