Speedy trial

Speedy Trial is a modified BIP-9 version bits deployment, written into BIP-341 itself rather than into a BIP of its own. Miners had 109 days, from 24 April to 11 August 2021, to set bit 2 in 1,815 of 2,016 blocks, with enforcement pinned to block 709,632. That enforcement height was fixed before signaling opened, so holders knew the exact block at which the rules would change.

How it works

Speedy Trial keeps BIP-9's counting method, changes two of its numbers, and adds one parameter BIP-9 never had.

BIP-9 tallies signaling blocks over each 2,016 block retarget period and moves a deployment from STARTED to LOCKED_IN as soon as one period contains enough of them. Its threshold is 1,916 blocks, 95 percent of a period, and its own guideline for the window is one year, 31,536,000 seconds after the start time. Both the start and the timeout are read from median time past, the median timestamp of a block and its ten predecessors, so the clock belongs to the chain rather than to anyone's watch.

The Taproot deployment cut the threshold to 1,815 blocks, 90 percent, and gave the window 9,417,600 seconds, from epoch timestamp 1619222400 to 1628640000. The addition was min_activation_height. Under plain BIP-9 a locked in deployment becomes ACTIVE at the next retarget boundary, so lock-in pins the enforcement height only to the 2,016 blocks that follow it. Under Speedy Trial the LOCKED_IN state loops until the chain reaches the stated height, and only then falls through to ACTIVE. Mainnet's height was 709,632, which is exactly 352 retarget periods and therefore a period boundary. The deployment did activate there.

The separation is the whole idea. Signaling answers one question quickly, and the long gap that follows is time for everyone else to upgrade rather than time spent arguing.

Where you see it

Speedy Trial's parameters are legible in the version field of every block mined during the 2021 signaling window.

A signaling block carries top bits 001 plus the deployment's own bit, so a Taproot signal on bit 2 reads as version 0x20000004. Miners requesting work meet the same deployment through getblocktemplate, whose "rules" key names the soft forks already active and whose "vbavailable" key maps each pending one to its bit. The name BIP-341 gives this deployment, and therefore the string a miner reads, is simply "taproot".

The testnet3 run of the same deployment shows what the delay was for. It used identical start and timeout timestamps, a threshold of 1,512 blocks at 75 percent, and min_activation_height 0, so nothing was deferred beyond BIP-9's own one period gap and it went active at height 2,011,968. Mainnet got the extra wait; the test network had no economy to protect. On signet the rules were always active, so no trial happened there.

Speedy Trial vs UASF

A user activated soft fork forces the outcome from the node side, and Speedy Trial deliberately refused that power.

The forcing mechanism is written down in BIP-8 as lockinontimeout. Set it true and the deployment gets a MUST_SIGNAL period before the timeout, in which blocks that do not signal become invalid once the period's allowance of non-signaling blocks is used up, guaranteeing lock-in whether miners cooperate or not. BIP-8 recommends the flag for any soft fork expected to face political opposition from a non-negligible share of miners, and in the same document warns that nodes running it may follow a lower work chain for an extended period and may need to peer preferentially with each other.

Speedy Trial carried no such flag. Missing the threshold before the timeout put the deployment in FAILED and did nothing else, which was the trade it made: no guarantee of activation, no risk of a chain split, and a cheap answer either way.