Thanks for your work. Regards Piotr
Progress! LTC is wonderful! We need an excellent spokesperson and publicist! It works so well!
Is the audit still planned to be completed by Mid October?
Thank you, my man!
no news this month ?
hello, last news was Aug 3, 3:14 AM. we will get august updates on September.
delay on the release is starting
** **
@litecoingva @David said he was merging code from 0.21 and take a look. For your surprise: https://github.com/ltc-mweb/litecoin/commits/0.21
He is indeed merging code!
August Progress:
Coding
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
For the code monkeys among you, the majority of the changes were in: scriptpubkeyman.cpp, mweb_wallet.cpp, and Keychain.cpp.
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…
Reviews & Audits
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.
Releases
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
Notable Mentions
Ryan Wright is an absolute baller. While I was searching for a quiet street corner to live (see: background), he swooped in with a 100 LTC donation just before I listed my house on the market
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.
September Progress:
v0.21 Release
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 lockinontimeout
set.
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.
Taproot Activation
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
DEFINED
state, 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
STARTED
state, 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_IN
state. It staysLOCKED_IN
for the next full window (8,064 blocks), allowing everyone time to upgrade. -
After being
LOCKED_IN
for one full window, Taproot switches toACTIVE
. 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
lockinontimeout
option 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. -
After being
LOCKED_IN
for one full window, Taproot switches toACTIVE
. 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.
Audit
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!
Regards,
Srinivas
October Progress:
Audit
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.
Findings
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
v0.21.1 (Taproot) Release
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.
MWEB Testnet
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
litecoin-63fe928e4e8a
folder - Find and run
litecoin-qt.exe
from 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.
Remaining Schedule
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!