Suppose to be March not Feb
And I believe that will be a testnet with full roll out later. Correct me if wrong.
There was supposed to be a new testnet a few weeks ago, but I found too many issues with the wallet transaction building & history logic, so chose to focus on rewriting parts of it instead. While this setback is unfortunate, I’ve been working extra long hours to make sure we continue to meet the self-imposed March 15th deadline.
As a reminder, the March 15th date is when we expect to have the initial code complete and a pull request opened to the main repo. For those unfamiliar with github terminology, that means the code will be complete to the best of my knowledge, and ready for review by other developers, and eventual inclusion into the main LTC codebase.
Excellent! Thank you for the positive clarification AND hard work! It sounds like positive results are very soon!
The LTC team, when they work together, seems to do what others have to find time-consuming consensus to achieve.
Congratulations to your hard work and all LTC users/holders out there who will benefit!
Could the addresses for mb be like
I’m very much in crunch mode now, and haven’t slept in days, so please forgive my incoherent rambling
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.
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.
- Testnet deprioritized again (yikes!)
- Coin selection kicked my ass
- Still shooting for code-complete on March 15th
Thank you, David! You rock.
Hi David - was there any integrations with the mingle jingle code from monero also?
If they don’t have enough money to hire more people to work, will you pay for them？
Let me answer this question for most people: I’ve lost so much in the past year that I don’t even have enough money to live well
Welcome to a decentralized currency with no premine.
Let the Man and his team work on the project and stop crying
Yeah, I’m spending both my money and time in helping Litecoin succeed. What are you doing for Litecoin?
At this late stage putting more coders to rush the project would delay the finish date even further out. It’s called Brooks’ Law.
Thanks for all you do for Litecoin.
Litecoin is a fork of Bitcoin and gets most of the improvements from Bitcoin. If Bitcoin succeeds, Litecoin benefits from that. So yes, I want both to succeed.
As for price, litecoin network is secure enough today. A higher price will not materially affect it. A higher price could get more people interested and therefore more adoption, but it’s a double edged sword. When the price shoots up too much, it crashes and lots of people get hurt from it. So I’d much rather prefer more stable increase in price versus volatile prices. And that’s why I try not to pump the price and create more volatility.
Slowly working towards adding more fungibility to Litecoin will help Litecoin in the long run. That’s what this project is all about.
Since you’ve been around for 10 years, you know that Litecoin doesn’t have a dev fund. So asking the community to help contribute towards this goal is the right thing to do for a decentralized cryptocurrency. I do what I can to help in terms of donation matching and spending my time on it without any pay from the Litecoin Foundation. Could I fund the whole thing? Sure, I probably could, but then what’s the point of this whole thing? We’re building a decentralized cryptocurrency for the world after all.
Thanks Charlie. We appreciate all that you have done.
Guess Grayscale buying 80% of all mined LTC says something . Plus I believe LTC is true transferable money, me and my friends love it. It works, what more do you want?
Thanks for being positive and patient with people Charlie. I appreciate everything you have done to create a fair and decentralised second global currency. Many around the world feel the same.