{"id":17683,"date":"2021-02-12T13:34:23","date_gmt":"2021-02-12T13:34:23","guid":{"rendered":"http:\/\/ci027cfe6cb0052697"},"modified":"2025-01-30T12:53:52","modified_gmt":"2025-01-30T12:53:52","slug":"bitcoin-developers-on-taproot-activation","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/bitcoin-developers-on-taproot-activation","title":{"rendered":"In First Activation Meeting, Bitcoin Developers Discuss Paths For Taproot"},"content":{"rendered":"
<\/div>
<\/figure>\n

Taproot was merged into Bitcoin Core<\/a> in October 2020, leaving only the activation method for this highly-anticipated protocol upgrade focused on adding smart contract flexibility and more transactional privacy to Bitcoin.<\/p>\n

Last week, the Bitcoin development community gathered via Internet Relay Chat (IRC) to discuss the parameters of the Taproot activation and two code pull requests (PRs) of the BIP 8 signaling mechanism. <\/p>\n

\u201cIn an effort to get this closer to the finish line we are organizing a meeting on IRC on the ##taproot-activation channel on Tuesday 2nd February at 19:00 UTC,\u201d Bitcoin development organizer Michael Folkson announced via the bitcoin-dev mailing list<\/a>. \u201cThe primary objective will be to finalize the revised BIP 8 activation method…\u201d<\/p>\n

Ultimately, that meeting provided more insight into how Bitcoin\u2019s most significant protocol change since SegWit might move forward.<\/p>\n

Editor\u2019s note: The statements reproduced from IRC below have been edited slightly for clarity but are otherwise presented as they were written.<\/em><\/p>\n

Giving Shape To The Proposal<\/h2>\n

Bitcoin developer Anthony Towns<\/a> has compiled the proposals and possible scenarios<\/a> for the activation of Taproot. In the February 2 meeting<\/a>, the ones that seem to have the most support are \u201cBIP 8 (false, 1y)\u201d and \u201cBIP 8 (true, 1y).\u201d However, no vote was taken, there was just discussion of each alternative activation method.<\/p>\n

But what does this mean? BIP 8 is a mechanism that allows for upgrading the consensus in the Bitcoin network through a soft fork, and, specifically a miner-activated soft fork or MASF with the option to add a user activated soft fork (UASF) after some time. In the last consensus update (SegWit), a user-activated soft fork (UASF) was used in addition to BIP 9’s <\/a>MASF. However, Taproot seems to be non-controversial for miners<\/a>, so it seems less likely that a UASF would be necessary this time.<\/p>\n

Coming back to the proposal, the parameters are \u201clockinontimeout\u201d and \u201ctimeout,\u201d where lockinontimeout<\/em>basically means whether or not the activation would be forced and \u201ctimeout\u201d means<\/em>the window in which it would be activated. Another relevant parameter that didn’t get enough discussion was \u201cstartheight\u201d. <\/p>\n

If lockinontimeout is false, and the update doesn\u2019t have enough support, it gets cancelled and a new proposal is defined. (Bitcoin Developer <\/p>\n

To clarify:
BIP8 w\/LockinOnTimeout is a MASF w\/ UASF fallback.
So long as miners activate, no UASF occurs.<\/p>\n

The pre-planned UASF also ensures the MASF happens:
It avoids giving the miners a veto power, and creates the proper incentive to ensure a MASF occurs.#Bitcoin<\/a>#Taproot<\/a><\/p>\n

\u2014 Luke Dashjr (@LukeDashjr) February 2, 2021<\/a><\/p>\n

“>Luke Dashjr described lockintimeout=false as giving miners an additional power that they were never intended to have),<\/p>\n

\u201cIf you start off with (timeout=T<\/em>, lockinontimeout=false<\/em>) there’s three possibilities when T is hit: the activation fails, you try again with a new activation (timeout=T+1yea<\/em>r, lockinontimeout=true<\/em>, eg); before then you tell everyone to switch their software to (timeout=T<\/em>, lockinontimeout=true<\/em>) at which point you’ve upgraded the MASF to a UASF,\u201d Towns wrote on IRC. \u201cThere’s also the possibility of getting everyone to upgrade to software that specifies (timeout=T-6 months, lockinontimeout=true<\/em>) in which case the people who’ve upgraded will start rejecting blocks at T-6months, and if the longest chain activates by that time, both old and new software will have the soft-fork activated.\u201d<\/p>\n

However, Dashjr disagrees on lockinontimeout=false:<\/p>\n

\u201c…are we happy with lockingtimeout = false in general?,\u201d Bitcoin Developer Maxim Orlovsky<\/a> asked.<\/p>\n

\u201cYes,\u201d Lightning Developer Rusty Russell<\/a> responded. \u201cWe have a UASF hammer if we need it, but obv it’s better not to use it.\u201d<\/p>\n

\u201clot=true doesn’t mean we use it, lot=false means the intent is to let miners decide,\u201d Dashjr wrote. \u201cBIP8(false) is a regression.\u201d<\/p>\n

But Russell argued against what he sees as a developer imposition: \u201cI feel that avoiding the appearance of developer mandate over the protocol is important, and also I like having an escape hatch should problems be found before activation,\u201d he wrote. \u201cThus I prefer to start with lockin=false, and revisit at 6 months if it hasn’t activated.\u201d<\/p>\n

\u201cThere\u2019s no developer mandate\u2026 makes more sense to do 1y,false then 1y,true for the same 1y period [in the case of two subsequent deployments],\u201d Dashjr responded.<\/p>\n

But Russell did not appear to be swayed:<\/p>\n

\u201cI disagree,\u201d he wrote. \u201cMiners get coordination power because we can reliably measure them in a decentralized manner, unlike other groups. That implies the ability to *not* coordinate, yes. But we have a plan for that too, as BIP-8 makes a UASF much less likely to cause a split. That’s as good as we can do.\u201d<\/p>\n

\u201clot=true IS planning for that,\u201d Dashjr wrote in response, \u201cit doesn’t stop miners from doing MASF.\u201d<\/p>\n

Others in the chat proposed to make lockinontimeout=false optional, but the default:<\/p>\n

\u201clot=false is safer than lot=true, so it’s worth doing lot=false first given that we know hashpower is ~90% already pro-taproot,\u201d wrote CoinSwap developer Chris Belcher<\/a>.<\/p>\n

Iif users can easily change lot=false to lot=true at some point without requiring a new core release, I’d support leaving lot=false the default,\u201d Keagan McClelland<\/a> wrote.<\/p>\n

The UASF Hammer<\/h2>\n
\n

To clarify:
BIP8 w\/LockinOnTimeout is a MASF w\/ UASF fallback.
So long as miners activate, no UASF occurs.<\/p>\n

The pre-planned UASF also ensures the MASF happens:
It avoids giving the miners a veto power, and creates the proper incentive to ensure a MASF occurs.#Bitcoin<\/a> #Taproot<\/a><\/p>\n

— Luke Dashjr (@LukeDashjr) February 2, 2021<\/a><\/p><\/blockquote>\n