Taproot[1], the proposed Bitcoin protocol upgrade for compact and privacy-preserving smart contracts, is getting closer to activation. The Taproot code itself had already been included in the most recent major Bitcoin Core release (Bitcoin Core 0.21.0), which is currently the de-facto reference implementation for the Bitcoin protocol. The next step was to deploy activation code for the upgrade to go live across the Bitcoin network.
But due to technical and philosophical disagreements on how the Bitcoin protocol should be upgraded, discussion about Taproot activation turned out to be a long and sometimes heated debate. Now, it has resulted in two different Taproot activation paths, embedded in two main software clients that could in some scenarios even become incompatible with one another.
This is the story of these main two Taproot activation clients, the difference between them and some possible scenarios going forward.
Background
Taproot activation has been the subject of discussion[2] since early 2020. Over the course of more than a year of discourse across the Bitcoin development mailing list, a dedicated IRC channel and other discussion forums, a rough consensus appeared to have formed around using the Bitcoin Improvement Proposal 8 (BIP 8) protocol to activate the soft fork. This would let miners activate the soft fork by signaling readiness, until a timeout is reached.
The final point of contention was around what should happen if not enough miners had signaled readiness when that timeout was reached, reflected in the Lock-in On Timeout (LOT) parameter. If LOT is set to ”false” (LOT=false), the upgrade simply expires at timeout, and a new activation mechanism can be considered. If LOT is set to “true” (LOT=true), however, nodes will from that point on only accept signaling blocks, and reject any non-signaling blocks. Assuming that enough signaling blocks
