Took an extra day because I was busy meeting obligations for the auditors, but I promise I will never forget the monthly update. Once again, please have patience. This is always a priority of mine, so repeated reminders don’t actually speed things up at all 
3 Likes
June Progress:
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 - 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 - 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 - 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 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, but overall, we’re still working toward MWEB activation at the end of the year.
13 Likes
#Litecoin Must Upgrade
1)Wallet address like dns (imagine use ip instead dns). Example:
fuorissimo.litecoin.com > pubblic key address
2)send/receive password: if wrong/not typed, abort trx. Security/stole/errors solved. This Is my 5 years battle
- DNS is centralized and requires way too much trust.
- This is ambiguous. Spend some time to actually develop a detailed idea (even if it doesn’t cover the technical aspects), then create a new thread with it. Spamming already-busy devs with a few non-descript sentences on completely unrelated threads across multiple platforms isn’t an effective approach.
5 Likes
Spamming? 
Good job
Please keep this thread to posts regarding MWEB, if you would like to discuss potential new features, please create a brand new post.
3 Likes
Except blake3 is more susceptible to brute force attacks, is it not? Maybe I just don’t understand it. I’m not very code savvy.
SHA2 is ~10x slower than blake3, so while theoretically that means it takes 10x longer to naively brute force, 10x longer than forever is still forever.
3 Likes
Is quantum computing really forever away though? Maybe this would be adequate for now but Im just thinking long term sorry.
Yes, most likely. But even if that weren’t the case, most hashing algorithms (including blake3 & sha256) are generally considered quantum secure.
3 Likes
MWEB will never be activated on the mainnet. But if suddenly, all the same, activation occurs, then this will become the destruction of Litecoin. Charlie knows it (LitePay remembering), but he doesn’t care
Would you mind explaining in another thread where your conclusions came from?
3 Likes
Great work and dedication, David B.
Thank you!
2 Likes
Hello @David, I heard the podcast you have been interviewed and also the presentation on Stanford. First of all, thanks. I think you and Charlie are admirable.
Also, as I have understood a little bit more (as I am not technical on aspects of cryptography) you are implementing a sidechain with MWEB using elliptic curves. That means the validation of transactions inside MWEB will occur inside MWEB thought Consensus rules .
That said, I suppose simpler implementations of MWEB could just transact inside sidechain without the ability to pegin and pegout. Right?
I mean if will be possible to write some specific piece of code (to use on regular day-to-day transactions for example) to run on my cellphone, so I could receive funds inside MW, to buy ice-cream and pay the cinema without disclosing how many LTC I own, and then get the change back to another wallet without the effort to have to peg-in and peg-out while I’m on the street.
Have I understood correctly?
1 Like
July Progress:
Coding
I’ve shifted away from writing new code so the MWEB codebase can remain stable while the auditors perform their review. I’ve been focusing instead on rebasing our changes from the LTC 0.18 branch to the LTC 0.21 branch.
For those unfamiliar with git terminology, what this means is we started with the code from the LTC 0.18 release (the latest at the time), and have been coding MWEB on top of that. However, LTC 0.18 is no longer the most recent code, since the release for LTC 0.21 is nearly ready. So I’m merging the MWEB code we wrote onto the LTC 0.21 codebase so that we still have all of the latest features (like taproot) in our MWEB release. This is a manual process that can be very tedious and time consuming, since code changes that were made in LTC 0.21 could interfere with the changes we made to support MWEB. These conflicts must be carefully addressed individually, which has been taking up much of my time.
Fortunately, I’ve finally got all of the node changes merged and building successfully. I’m working on fixing some failing tests, and then I will start doing the same thing with the wallet code. Once that is all finished and reviewed, we should be able to make a pre-release to start testing how the code works on mainnet. In particular, we’ll focus on making sure it communicates fine with older nodes, validates and propagates transactions & blocks, does not prematurely enforce MWEB rules before activation, and is able to successfully mine valid blocks.
Reviews & Audits
Members of the team developing Tari were kind enough to spend some time to give a high-level review of the design & code. They provided us with their findings here and here. In addition to finding a few potential issues, they’ve also thoroughly documented their understanding of the changes, which can serve as a useful resource for others trying to learn about MWEB.
Also, we received the official audit proposal from Quarkslab, which we’ve accepted[*], so they will be officially starting their audit in just a few days. This is expected to wrap up by mid-October, when we will be provided a report of all findings. Once we address the issues found, we’ll be able to create an official release (release number TBD).
[*] Thorough auditors like Quarkslab can make all the difference in the success of a project. Unsurprisingly, this means they can be quite pricey. By “we’ve accepted”, what I really mean is Charlie has, since he generously chose to pay for this audit. We are very fortunate to have him around 
I had to take some time off this month for personal reasons, so my update was a little lighter than we’ve been used to. Things will be back to normal next month. Thanks for your understanding.
35 Likes
I am glad to hear that you took some time off. Been a healthy and unstressed coder is must have ‘feature’ to have quality and secure development. Many thanks for the progress update, I am sure must of developers here understand the tedious process of merging code.
8 Likes
Completion will be huge for LTC. Good job, and thank you for keeping us updated here.
1 Like
I choose LTC as my No.1 crypto because of you and @coblee . I believe in you both 100%. Great work! Thank you
4 Likes
Truth - thanks @coblee for everything - and probably getting Tari to help out (thanks to FluffyPony)
Excellent update as well, great to read about the rollout and new audit
Keep up the great work David
6 Likes