MWEB Progress Update Thread

Development
275

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:

  1. Taproot will initially be in the DEFINED state, which just means it’s a known feature but can’t be voted on yet.

  2. 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.

  3. 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 stays LOCKED_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 :rocket:

    • 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 :partying_face:

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 :tada:

33 Likes