delay on the release is starting
He is indeed merging code!
Last month I merged the
node code on top of the LTC 0.21 release codebase (see July update), so this month began with me merging the
wallet code. It turns out that a lot changed in the wallet between 0.18 and 0.21, so I had to spend a few weeks redesigning how we calculate and manage MWEB addresses and keys. The end result was even cleaner than we had with 0.18 though, so this turned out to be a good thing, despite requiring the extra effort
Aside from that, I had a lot of bugs and tests to fix as a result of the merge, which I was able to do just in time for the auditors at Quarkslab to include in their review. On that note…
I’m working very closely with one of the Quarkslab auditors now. She has been going over the code and is in the initial stages of testing. We were able to get her synced against mainnet, and she also requested I create a testnet for them, which they’re now connected to and experimenting on.
While we’re now merged on top of 0.21 release code, we actually haven’t even released 0.21 yet . I was asked to take over managing this release, so I spent the past week getting that release code ready. Assuming I can herd the other devs together (which is a lot like herding cats), then I expect we’ll be able to have 0.21 released by my next update. This will include, among many other things, support for Taproot .
Hopefully we can get 0.21 adopted quickly, and miners signaling for Taproot, because the following month, I’ll be cutting the release for MWEB (which I’m calling
0.22-ish until someone gives me an official release number). The release date for
0.22-ish will be highly dependent on the results of the audit, which won’t be completely finished until mid-October. So while we’ll remain optimistic for an October 31st release for now, write the date down very lightly in pencil, not pen
MWEB is now fully funded!
All additional donations collected will continue to fund me for future development projects. There’s still so much more I want to do: Dandelion for P2P-level privacy, CoinSwap support, syncing improvements, Atomic Swaps, watch-only addresses, MWEB support for hardware wallets & light clients, and much, much more. So still chip in whenever you can
David. We would love to keep funding further development. We appreciate the long hours & late nights! Along with the continuous updates.
The taproot launch then the MimbleWimble upgrade are exciting advancements on the litecoin network that will bring in better signature/contract capabilities & scalable confidential transactions.
I was hoping to have the v0.21 release out already, but I’m waiting on one last developer to review. A couple of us have already run through a test build to make sure our environments are setup correctly, so once everyone has signed off on the code, we should be able to get a release candidate built and signed fairly quickly.
The most notable change in v0.21 is the inclusion of Taproot support. The Taproot logic is the same as in bitcoin, but activation will be done differently. We chose to trial the mechanism we’re planning to use for MWEB activation, which is bip8 with
Soft fork activation can be hard to follow at times, because there’s a few different ways it can be done (BIP8, BIP9, UASF, etc.), and activation takes place through a number of steps or “states”, that aren’t usually explained well for non-technical users. I want to make sure everyone can follow what’s happening, so we’ll walk through the process for activating taproot.
Each block has a
version field, which miners can use to “vote” for soft forks. Miners will be using a small part of the
version field to signal for Taproot activation.
Every 8,064 blocks, a new “window” is started. At the end of each window, nodes tally up all of the blocks that signal for a feature, and if the total meets the defined threshold, the feature “locks in” for activation in the following window. In our case, the threshold is defined as 6,048 blocks or 75% of the blocks in the window.
So here’s how this will look for Taproot:
Taproot will initially be in the
DEFINEDstate, which just means it’s a known feature but can’t be voted on yet.
At block 2,153,088 (early- to mid-November), the feature will switch to a
STARTEDstate, meaning upgraded miners can start signaling/voting for activation of taproot. After 8,064 blocks (the first window), nodes will add up the number of blocks that signaled for Taproot activation.
The process repeats until one of two conditions is met:
A window occurs with at least 6,048 (75%) of the blocks signaling for Taproot:
At the end of this window, Taproot switches to the
LOCKED_INstate. It stays
LOCKED_INfor the next full window (8,064 blocks), allowing everyone time to upgrade.
LOCKED_INfor one full window, Taproot switches to
ACTIVE. Nodes begin enforcing Taproot consensus rules for all blocks
If the threshold is NOT met by block 2,362,752 (Nov 2022), we rely on the
lockinontimeoutoption I mentioned earlier:
Taproot switches to
LOCKED_IN, despite not meeting the threshold. Miners must start signaling for Taproot. Any block that doesn’t signal for Taproot will be ignored by the nodes on the network.
LOCKED_INfor one full window, Taproot switches to
ACTIVE. Nodes begin enforcing Taproot consensus rules for all blocks
I hope this is easy enough to understand, but if any of it is unclear, the full BIP8 spec is available here.
I met with the Quarkslab auditors Wednesday for a mid-audit check-in. They’re wrapping up their static analysis of the code, and have found very few issues so far, which is very encouraging.
We also discussed priorities for the remainder of the audit, to make sure the most important pieces are thoroughly covered.
For the next few weeks, one auditor will be focusing on manually testing, trying to make sure it works as expected, and more importantly, trying to see if they can break it.
The other auditor is knowledgeable on cryptography, so will be focusing heavily on the one-sided tx design (LIP-0004) to make sure we didn’t miss any attacks that could compromise key integrity, lead to tx malleability (i.e. allowing someone to modify a transaction that they aren’t the creator of), or any other number of security issues.
I expect us to have the results of the audit in just a few weeks
Hi David. Thanks for the update & hard work. What a great idea with taproot activation.
We appreciate your focus & consistency to making litecoin the best currency for the people by the people.
10 years 100% uptime.
You are THE best
Waiting for the November update like Hawk
It’s going to be worth the wait @vasajb. I was hoping to have written it already, but I’ve hit a couple roadblocks. Hopefully not too much longer
Absolutely! Really Appreciate all your consistent work over few years on this Project. Being software engineer myself - I know its not easy task… Thanks Again!
Quarkslab has finished their audit of the code!
I’ll be meeting with them Friday to discuss their findings. After that, they’ll work on releasing the audit report in a blog post, which I look forward to sharing with you all.
Since you’ll be able to read the full report once they share their blog post, I won’t dive too deeply into the findings here. But at a quick glance:
There was one critical issue found that resulted from a mistake while merging the MWEB code & v0.21.1 code together. So when copying the changes into the latest release code, I missed a small, but crucial line of validation code that could’ve been exploited by a malicious attacker to cause serious disruptions to the chain
This tells us…
We could really benefit from better functional test coverage around our validation logic to make sure we would catch similar issues ourselves in future releases.
We should think about adding some processes we can follow to minimize the possibility of this happening. That could mean documenting all changes, or having 2 people perform the merge separately then comparing results, or a change to how we approach the code reviews.
The audit was a really good idea (thanks Quarkslab!)
There were also some smaller findings, and some great suggestions for how we could improve the quality and safety of the code. Overall, they were impressed with the code quality, which was exciting to hear
The release process we inherited from bitcoin can be quite painful. It uses gitian to build repeatable and deterministic binaries from the source code. This means that multiple people can all build the code on different machines (and even different operating systems) and still get the same exact release binaries. We can then all compare the results and then sign the release, certifying that we all agree that the published release is safe & accurate.
There’s a lot of magic involved to make this work, which leads to a time-consuming & often frustrating experience (especially for n00bs like me). So I really dragged my feet on this one . I finally forced myself to push through this a few days ago, and after fighting with some outdated scripts, was able to build all of the binaries successfully. I’ll finish signing these tomorrow and hand them off for the other developers to repeat the build & verify results.
After lots of promises and then take-backs, I’ve finally decided to release a binary that allows non-technical users to try out the MWEB testnet. I only have the windows release available right now, but I’ll work on getting binaries for Mac OS X on Friday. Linux users can build their own, because I’m tired
Link: MWEB Testnet Release
Here’s my gpg key if you’d like to verify the binaries first (you should). I’ll add instructions on how to do that on the release page when I have some time.
There’s no installer, because I didn’t want anyone accidentally replacing their actual litecoin wallet, so to use it:
- Download (and verify) the zip file
- Extract the
- Find and run
litecoin-qt.exefrom inside the bin folder
This will default to using the MWEB testnet, which you can tell by the off-colored logo and the
[mwebtest] in the title bar. These use mwebtest coins, not actual litecoin coins. So pleeease don’t try to use it with real money.
You’ll either have to mine a block to get mwebtest coins (you can CPU mine a block in no time), or find someone to give you some. If anyone is willing to setup a faucet, I’ve got a ton of coins you can have
Also, if someone feels like writing a guide for how to create stealth addresses, send to and receive from them, and all of the fun stuff that goes along with it, you’d be my new favorite person.
You’re pretty much back to just waiting on me again while I finish applying audit suggestions and then pushing through the tedious process of merging, coordinating final reviews, writing release notes, and finally kicking off the beloved gitian builds. I don’t know exactly how long that will take, but rumor has it that it increases by a full day for every person that asks me
What a long journey this has been
P.S. https://wenmweb.com is up to date.
Amazing work mate! Congratulations on this milestone!
hi David, my name is wasim and I am big fan of LTC, I always believed in Crypto Since the start, i carry massive investment in LTC and I would love to be part of the coming up on LTC, do you mind if we can have a meeting to discuss further your hard work.
Thank you so much David…your work is amazing
Really hope you’ll be held as a King after MWEB is activated
Litecoin is about to have its largest upgrade of all time. MimbleWimble technology offers a way to allow for private transactions making litecoin one of the best digital cash options.
We look forward to seeing litecoin lead again as we develop better sound money for the people.
hi David. Interesting. I’ll try this Release MWEB Testnet Release · ltc-mweb/litecoin · GitHub
and give feedback.
One question: in case bitcoincore wants to use this MWEB, is it compatible or near compatible for btc?
runing ok on win8/es.
only one peer: 22.214.171.124:49339 (ID de nodo: 0)
pls, some test-LTC to tmweb1qqgunzszdkghjd8wemyh9g0w78hewk7a9dcpnhjq3fy6q34r8q4ydsq59mrfdw3t7utj84md82nwkd768lrgwdzrjywc8v9ym6ts02v5zduldjz0e
or this one (with label and message)
What is happening with taproot signal?