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.
