I’m very much in crunch mode now, and haven’t slept in days, so please forgive my incoherent rambling
February Progress:
The expectation was that I would have a community testnet launched, but I have failed yet again
Sorry about that!
I was all prepared to launch it, but wanted to “quickly” (HA!) add the logic for automatically pegging-in when sending from a LTC output to an MWEB address (and vise-versa) so users who weren’t real familiar with the intimate details of pegging-in & out could still send and receive MWEB transactions. But the more I dug into it, the more I realized our wallet design just didn’t mesh well with the existing LTC wallet at all.
It started with coin selection. If you’ll recall, LTC works by spending coins you’ve received before and creating new coins of equal or lesser value for another user’s address (and change back to yourself). The process for selecting which coins to spend is incredibly complex, since poor choice of coins can lead to paying excess fees or serious privacy leaks. In fact, it’s so complex that bitcoin developer Murch wrote his 67-page master’s thesis about that single topic[1].
Up to this point, we hadn’t needed to make many changes to the coin selection logic, since we were either sending LTC coins - in the case of a typical LTC transaction or when pegging-in (sending LTC coins to an MWEB address) - or we were sending MWEB coins - in the case of an MWEB-to-MWEB transaction or when pegging-out (sending MWEB coins to a LTC address). This was relatively straightforward to implement, since it meant simply applying Murch’s algorithm to the available LTC coins (for LTC-to-LTC or when pegging-in) or applying Murch’s algorithm to the available MWEB coins (for MWEB-to-MWEB or when pegging-out). There was no “mixed” mode where some LTC coins were sent with some MWEB coins.
That all changed when I wanted to add the ability to automatically peg-in/out without requiring the user’s knowledge of how that works. Now, we could get ourselves into all kinds of weird scenarios. If a user decides to send to an MWEB address, the wallet first checks if they have enough MWEB coins to just send them in a normal MWEB-to-MWEB transaction. If they don’t have enough, then we check if they have enough LTC coins so we can just create a peg-in transaction (LTC-to-MWEB). But if they have 5 LTC coins and 7 MWEB coins, and they want to send 10 coins to an MWEB address, then we have to create a mixed MWEB transaction which spends some from the LTC side and some from the MWEB side, creating a sort of partial peg-in tx.
And it gets even worse…
If we change the scenario to wanting to send 10 coins to a LTC address, but they only have 5 LTC coins and 7 MWEB coins, we actually can’t just peg-out (MWEB-to-LTC) 5 of those MWEB coins and combine them with the 5 LTC coins. Due to the structure of the transactions, we actually have to peg-in those 5 LTC coins, combine them with the 7 MWEB coins, and then peg-out 10 of those. Doing this all in one transaction and deciding the best coins to use - all while trying to minimize changes to the existing LTC codebase - has kept me up for weeks. So much for “quickly” adding that in
So if anyone is looking for a master’s thesis topic, consider going with An Evaluation of Coin Selection Strategies for Mimblewimble Extension Blocks
Moving on, I finally figured out the coin selection logic, and started doing some manual testing of the new code. Immediately, I started finding all kinds of weaknesses with the wallet code that simply weren’t a problem when we didn’t have mixed/partial MWEB transactions. So I had to rethink the entire design of the wallet (fortunately, the much-more-critical consensus code remains in great shape).
To make a long story short, I rewrote about 80% of the MWEB wallet code to support mixed-coin MWEB transactions. While I tossed around the idea of launching the testnet in parallel without this new functionality, the wallet rewrite more than burned through all of the buffer I had left in the timeline. The time I would’ve spent supporting the testnet certainly would’ve delayed the March 15th code-complete deadline.
But the good news is we’re (mostly) back on track again!
I guess I’ll just kick the can a little bit further down the road, and shoot for launching a community testnet sometime after the code is completed this month. There’s still a ton of work left to do before the code review can be submitted, but I remain confident & committed to meeting the March 15th goal.
TL;DR:
- Testnet deprioritized again (yikes!)
- Coin selection kicked my ass
- Still shooting for code-complete on March 15th
[1] https://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf