Hi David, Hope you are well. Do you have any update for us?
Updates are only in the slow test, you have to donate more Ltc and then tell you
Hello Litecoin community----- I recently reached out to David; I am sure he is quite tied up with all of the development taking place currently. I wanted to genuinely inquire if there were any actions we as a community could take to bolster the testing and successful implementation of Mimble. In addition, if anyone other than David is aware of the current status, please feel free to chime in.
May the force be with us !
I appreciate the enthusiasm from everyone, but please be patient (I’m not even late yet ). If you’ll scroll back and look at my previous updates, you’ll see that nearly every one of them is posted on the evening of the 1st (EST). This month will be no different. I will provide the monthly update in just a few hours. Thanks!
David just told me he has a lot of good news to share.
We were able to get Grin++ ready in time for the hardfork, which went smoothly. That was the final planned fork, so Grin++ is back in maintenance mode, and should no longer be a distraction for the remainder of this project
The bad news - I was not able to get the automated windows build ready, so I did not kick off the community-wide testnet this month like I hoped.
The good news - The delay was mostly a consequence of a new proposal by Tevador (lead developer of RandomX) called MingleJingle. MingleJingle is another design for providing non-interactive txs in Mimblewimble, and by far the most detailed one yet. Tevador was able to use his extensive experience with Monero stealth addresses to make a number of improvements on our design (LIP-0004). The benefits of his design for sub-addresses and output encoding were immediately obvious, so I decided to switch gears for a bit and use what I learned from MingleJingle to improve MWEB addressing and output structure.
The big advantage of this new addressing scheme is that we no longer have to “grind” through different possible stealth addresses when restoring from a wallet seed. With my far-inferior design, the wallet would have to scan the MWEB utxo set and attempt to restore using the private keys once for each stealth address. So if you generated 10 different stealth addresses in the past, it would scan the UTXO set 10 times, which could take several hours after a decade of MWEB usage. While stealth addresses allow reuse without leaking information about your transactions, if you wanted to maintain several identities with a wallet (lame example: multiple pseudonyms on a site like litecointalk.io that each advertise a donation address), then each identity would still need to generate its own stealth address, resulting in these long scan times. But with Monero’s subaddresses (and Tevador’s improved version), we only have to scan each UTXO once, regardless of how many stealth addresses you’ve generated in the past
Some more good news - After finishing the new addressing improvements, I took another pass at the UI and transaction history display and found a number of ways to make it easier to follow where funds are moving. One change I made was to add a new column for MWEB amounts in the transaction history, so peg-ins & peg-outs look a little more intuitive:
The code is now ready for the new testnet, which we can launch as soon as we’ve get a working windows build. If anyone has experience setting up automated builds of bitcoin or litecoin for distribution on windows (preferably using Github Actions, but any CI would be fine), I could really use your help! Come chat with me at Telegram: Contact @MWEB_Testnet
The great news - There are still a ton of ways we can (and will) continue to improve the MWEB code, in particular around syncing, but most of what remains is not required for initial launch. So I think I’m finally ready to commit to a code-complete* timeline…
I will be submitting the code for review on March 15th.
This will contain all of the consensus, P2P, and wallet code necessary for supporting MWEB. The only thing it will be missing is the activation code, which I will add after the reviews and audits are all finished.
* Code-complete means ready for developer reviews & formal audits. It will not be ready for activation until after all reviews & audits are finished.
Happy Groundhog Day everyone! Although COVID killed the in-person celebrations here in Punxsutawney, you can still watch this crucial event unfold live from the comfort of your home: https://www.groundhog.org/
Hi David. Great update. The improvement to add the monero subaddresses by Tevador sounds like a much better way. I look forward to learning more.
Thanks again for all your hard work! I genuinely think you are building a revolution of money & freedom before our eyes.
I can’t wait to know the progress every month, only this day will come here to see, looking forward to March 5. thks
The ability to make confidential transactions on the Litecoin network - it will be cool
I was looking researching potential coins for holding long term . I found news of David in twitter regarding Mimblewimble . Its really great . I hope the last biggest adoption of litecoin was when release of the mobile wallet . Now private transaction option would be great implementation . Hope it will make look back into litecoin . Like ethereum 2.0 .
So crazy that you live in Punxsutawney, watched the movie on Groundhog Day, had no idea it was actually a real thing!
Many thanks David for such a great news! Say hello to Phil and stay safe!
Testnet will be in February?
I have some questions regarding MWEB which I did not fully understand.
- Will MWEB just shield the transaction amount or sender and receiver address as well ?
- will you first have to move LTC from the main chain to MWEB from your regular LTC wallet address to your OWN MWEB address or can you directly send from your LTC to someone else on MWEB
I believe before enabling MWEB the Litecoin community must educate the public what exactly MWEB does and how it works, else we might face backlash.
You can see the sender/receiver addresses, but it will use stealth addresses, so addresses are never reused.
Originally, we planned on requiring users to peg-in to their own MWEB address first, but after thinking through it some more, we realized we can probably* get away with allowing people to send directly to someone else’s MWEB.
* We’re still debating the need for peg-in & peg-out maturity (similar to coinbase maturity) which is the only thing that would affect this decision.
Thank you vm for the explanation.
Personally I believe it is key to have some privacy. For my own safety no unauthorized person / company should be able to see how much money (crypto) I own or where I transfer it to.
But to survive (government) in the long run I think it should support the travel / FATF rules. Like >
- on request any transfer should be traceable / unlockable (from whom to whom and how much)
Otherwise over time LTC might get banned from governments and subsequently removed from exchanges.
Say law enforcement / a judge rules you must disclose all your transactions from your LTC wallet, your personal key / unlock should then reveal all transactions from your wallet to whom, how much, what date & time, payment reason. While without ruling from a judge or the person refusing to unlock > the transactions remain anonymous to protect the privacy.
“Governments can suck it.” -Satoshi, probably
The little I know I do think governments won’t have any problem with MW. It’s not like it makes it Monero while protecting the consumer along with faster transaction speed and even lower fees.
As a miner, when shall we start signaling MWEB ? What is the timeframe of implementation ?