CoinSwap sounds friggin perfect! I’m a new recruit, portfolio severely down since buying in but I believe in LTC, and the amount of work that the developers have got going on, both in this forum and on various subreddits, is astounding. And props to Charlie for giving LTC major brand recognition!!
MWeb will bring serious fungibility to Litecoin, it’s an extremely exciting development, and to know how much code and how much painstaking work goes into it makes me that much more excited for its implementation!
They’re unrelated. Coinswap is a privacy technology used to obscure the ownership & origins of coins. DEXes (like Thorchain) are for converting between different asset types.
Thank you very much for the clarification. So it is not about swapping between currencies but within LTC for privacy purposes. It’s clear now, and I agree: a great feature. Thank you for all the work!
We’ve made the following significant improvements to the code over this past month:
Unified the build process to support existing release strategies. We originally intended on sharing the libmw codebase with Grin++, so the new code used a different technology (cmake) for managing builds than the existing litecoin code.
That plan turned out to be unworkable due to significant differences in the Grin and MWEB protocols, so there was no longer a reason to continue using 2 different build management solutions.
We’ve stopped using cmake entirely now, and just include the libmw code as part of the existing (automake) build. We’ve also downgraded from C++ 17 to C++ 14 to support gitian builds, which is how we generate verifiable releases.
Removed superfluous interfaces and boilerplate code. This also stemmed from the fact that we no longer need to share logic with Grin++.
We had a rigid interface layer that prevented us from calling the existing litecoin code from within the new libmw library, which resulted in the need to duplicate serialization, logging, and other infrastructure code within libmw.
Since litecoin is now the only consumer of libmw, we were able to eliminate this artificial separation, resulting in less code (and hopefully fewer bugs) overall.
Working automated builds for multiple platforms. The automated builds are working again for linux, and now also a windows build is being generated with each code commit.
This has allowed for quicker feedback from changes, and opened the door for non-developers to help out with testing without needing to build the code themselves.
Reviews & Audits
We’re still struggling to get developers to review the libmw code. The code has changed quite a bit since the PR was first submitted though, so I will likely be closing it and creating a number of new, smaller, and hopefully more digestible PRs over the coming weeks.
I met with Quarkslab yesterday to discuss what we need audited, and I will continue to work with them over the next week or two while they gather what they need to do their initial assessment & estimate for the audit.
We remain on track for activation around the end of the year, barring no major surprises from the auditors
Excellent! Would also love to understand what EB features will become available outside MW, if any. The community appreciates your diligence David, Litecoin Facebook group is reacting positively to this update ((no suprise))
Thank you for your response. I like your prospective. Litecoin is meant to be a currency. If it’s used as such it’s better for adaptation. My concern was for Paypal since it is such a large adaptation of the currency. However, as another user mentioned it is likely an opt-in so this may not even effect its use on Paypal.
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
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.
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.
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.
