This update was written and provided by Litecoin MimbleWimble lead developer David Burkett.
——–
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 6 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 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
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 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 6.
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