I’ve re-written LIP-0002 based on feedback received. The revised version is available for review here. The LIP-0003 re-write is still in progress.
I’ve also improved some of our code documentation, and will continue to do so over the next few months.
Coding & Testing
Hector Chu has helped a lot these past 2 weeks with testing & coding. He tested the major flows and quickly identified & helped fix a number of bugs. He has also helped with adding functional tests to cover some of the untested & under-tested consensus rules.
I’ve been working through the litecoin side of the code, and doing my own pre-review of the code before submitting it for review. I was able to clean up a lot of the validation and mempool logic to harden it against attacks, as well as fix some bugs in the wallet code.
Reviews & Audits
Hector has finished his review of the libmw code. I’ve addressed a number of the issues he found, and will continue to work through that list over the next few days.
Once the code for Litecoin’s v0.21 release has been reviewed, I’ll merge all of the MWEB code into that branch and submit the 2nd and 3rd code reviews (2nd=validation, mempool, & mining code; 3rd=wallet code).
I’ve also reached out to Quarkslab with the hope that they’ll have capacity to audit the design & code.
Instead of going over May’s tasks, which are going to be more of the same, I promised I’d discuss something fun about MWEB instead.
One thing that was proposed to Grin earlier this year by John Tromp was a “CoinSwap” service. If you’ve got a decent understanding of the math behind mimblewimble, then I recommend reading his proposal here.
This CoinSwap proposal aims to improve transaction unlinkability, much like a CoinJoin service does. But existing designs for MW CoinJoin services have a few important limitations. One is they currently require trusting the CJ server operator to not leak your transactions (there may be ways to eliminate that trust, but none have been found yet). Another is that using CoinJoin services have more annoying UX, since you must wait for the CJ server to aggregate enough transactions before the large CJ transaction is finally broadcasted and confirmed on chain.
CoinSwaps merely swap a single output for a different one of the same value (minus a very small fee). There’s no need to link any of your inputs together, risking revealing your identity to the CJ server operator. And you don’t have to trust any single server to preserve your privacy, since that trust can easily be spread over a large number of CoinSwap servers, with the requirement that only one of them needs to be honest in order to protect the privacy of all of the participants.
And this can all happen behind the scenes without any user interaction! When your wallet identifies new coins that were sent to you, it can automatically send those coins to the CoinSwap service to be trustlessly replaced with a different coin, so that once they’re mixed, even the person who sent you the coins won’t even be able to tell when or if you’ve spent them. The same can be done automatically for your change outputs when you send coins, or can just periodically be done by your wallet to ensure you’ve got clean coins.
The design appears to work as is, but I’m optimistic it can be improved even further to allow dynamic selection of coinswap operators. In its current form, the coinswap server list must be static. But if we allow the ability to easily add coinswap operators, you could always just add an additional one if there’s ever any fear that the existing servers have been compromised.
It’s worth keeping an eye on CoinSwaps. They help eliiminate Mimblewimble’s greatest weakeness (transaction linkability), and can easily be integrated into MWEB wallets, which means this is an excellent opportunity for someone to build a profitable business, while improving LTC’s fungibility at the same time.