Taproot was merged into Bitcoin Core 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.
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.
“In 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,” Bitcoin development organizer Michael Folkson announced via the bitcoin-dev mailing list. “The primary objective will be to finalize the revised BIP 8 activation method…”
Ultimately, that meeting provided more insight into how Bitcoin’s most significant protocol change since SegWit might move forward.
Editor’s note: The statements reproduced from IRC below have been edited slightly for clarity but are otherwise presented as they were written.
Giving Shape To The Proposal
Bitcoin developer Anthony Towns has compiled the proposals and possible scenarios for the activation of Taproot. In the February 2 meeting, the ones that seem to have the most support are “BIP 8 (false, 1y)” and “BIP 8 (true, 1y).” However, no vote was taken, there was just discussion of each alternative activation method.
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 MASF. However, Taproot seems to be non-controversial for miners, so it seems less likely that a UASF would be necessary this time.
Coming back to the proposal, the parameters are “lockinontimeout” and “timeout,” where lockinontimeout basically means whether or not the activation would be forced and “timeout” means the window in which it would be activated. Another relevant parameter that didn’t get enough discussion was “startheight”.
If lockinontimeout is false, and the update doesn’t have enough support, it gets cancelled and a new proposal is defined. (Bitcoin Developer Luke Dashjr described lockintimeout=false as giving miners an additional power that they were never intended to have),
“If you start off with (timeout=T, lockinontimeout=false) there’s three possibilities when T is hit: the activation fails, you try again with a new activation (timeout=T+1year, lockinontimeout=true, eg); before then you tell everyone to switch their software to (timeout=T, lockinontimeout=true) at which point you’ve upgraded the MASF to a UASF,” Towns wrote on IRC. “There’s also the possibility of getting everyone to upgrade to software that specifies (timeout=T-6 months, lockinontimeout=true) 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.”
However, Dashjr disagrees on lockinontimeout=false:
“…are we happy with lockingtimeout = false in general?,” Bitcoin Developer Maxim Orlovsky asked.
“Yes,” Lightning Developer Rusty Russell responded. “We have a UASF hammer if we need it, but obv it’s better not to use it.”
“lot=true doesn’t mean we use it, lot=false means the intent is to let miners decide,” Dashjr wrote. “BIP8(false) is a regression.”
But Russell argued against what he sees as a developer imposition: “I 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,” he wrote. “Thus I prefer to start with lockin=false, and revisit at 6 months if it hasn’t activated.”
“There’s no developer mandate… makes more sense to do 1y,false then 1y,true for the same 1y period [in the case of two subsequent deployments],” Dashjr responded.
But Russell did not appear to be swayed:
“I disagree,” he wrote. “Miners 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.”
“lot=true IS planning for that,” Dashjr wrote in response, “it doesn’t stop miners from doing MASF.”
Others in the chat proposed to make lockinontimeout=false optional, but the default:
“lot=false is safer than lot=true, so it’s worth doing lot=false first given that we know hashpower is ~90% already pro-taproot,” wrote CoinSwap developer Chris Belcher.
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,” Keagan McClelland wrote.
The UASF Hammer
Dashjr wants to use “BIP 8 (true),” a UASF fallback, as a game theory device to make sure that miners will activate Taproot, and give them no option of “veto” power, just like what happened with SegWit.
“Given the signaling requirements, What type of stalling or griefing attack could a mining pool achieve if they value stalling taproot?” a user called “gloved” asked in the IRC on February 2. “Eg abusing the marginal hashrate required for activation.”
As a reminder, signaling is about reducing fork risks and has nothing to do with political support or voting.
“MASF is the preferred path, with UASF as a fallback if miners fail to signal,” Dashjr wrote back. “The community could move the UASF sooner if it’s clear someone is stalling it.”
PRs 1020 and 1021
To make BIP 8 functional, it would have to be modified. This implies changes in the signaling mechanism and these are the code PRs that aim to do so:
- 1020: Would make miner signaling unnecessary after the LOCKED_IN phase, as by this phase the soft fork is already definitely going to be activated.
- 1021: Allow some MUST_SIGNAL blocks to not signal.
1020 had obtained acknowledgement in the February 2 meeting, and 1021 was initially considered unnecessary.
“Ok, so 1021 is only relevant when miners have NOT activated the fork,” Dashjr wrote. “1021 is in the UASF scenario ONLY… it allows up to 5% of blocks to be missing the required signal… IMO this is pointless and just increases complexity.”
But later on in the exchange, Blockstream researcher Nick Jonas pointed out 1021 could be necessary.
“Re #1021, if you decide run bip8(true) with most nodes still running bip8(false) you really wouldn’t run code that doesn’t implement #1021 because you might end up on the wrong chain otherwise,” Jonas wrote.
“Nick has a strong point,” Dashjr responded, later on in the IRC. “Without 1021, you could run LOT=true and fail to follow the Taproot-activated chain!”
In another exchange relevant to these PRs, Towns noted how these PRs could be relevant for the potential of bad actors.
“(1) the argument here is that during a UASF, requiring signalling creates a risk of chain splits — if a block doesn’t signal, a non-UASF miner will build upon that, but everyone knows both blocks will be rejected, so that’s an opportunity for attackers to double spend. accepting as many non-signalling blocks as possible (ie, up to 5%) limits that attack,” Towns wrote. “(2) the other consideration is if you start with a longer timeout (timeout=2 years, lockinontimeout=true/false) and then want to speed up the activation, because everyone’s upgraded, markets say they want it, and there’s 6% of miners who are trying to convince everyone bitcoin sucks and we should move to another chain, then we can set (timeout=1 year, lockinontimeout=true).”
“But these miners will create a problem once we reach 5% anyway, right?” Dashjr asked.
“‘Create a problem once we reach 5%’ — yes,” Towns responded, “if there’s >threshold miners they can create a problem; if there’s only 2% or so, this avoids there being a problem if we do the shorter timeout with lockinontimeout=true, then if we hit the timeout, and get 98% of blocks signalling but not 100%, this ensures everyone remains in consensus, and even if it’s the 98% chain that continues with the longest weight, the people who did the bip148-style speedy UASF don’t have to downgrade their software.”
“Given 1021 is the UASF scenario only does it need to be merged until an unlikely point where it is needed?” Folkson asked.
“Yes, it’s only meaningful if ‘old’ nodes run this code,” user ghost43 answered.
In the end, both PRs were merged.
In Summary
BIP 8 (which is a variant of BIP 9) appears to be the most serious activation mechanism at the moment. But there is controversy over whether the activation should be firm, even if it represents the risk of a UASF, denying a veto power to the miners; do it safely with the probability of delaying activation in case of insufficient signaling; or set false as default and if necessary, activate true. The supporters of the first option think that miners should not have to be able to disrupt a community process, while supporters of the second option think a UASF fallback is unnecessary and shows an unjustified imposition since miners have shown acceptance of Taproot.
PR 1021 is a safer general bugfix of BIP 8, since it prevents a chain split in some cases where more than 95 percent but less than 100 percent of all hash power supports the soft fork.
The next Taproot activation meeting (Tuesday, February 16 at 19:00 UTC) is set to be focused on code review, which will be followed by another meeting to discuss the parameters. As the discussion continues, Bitcoin gets closer to its most significant protocol upgrade in years.
This is a guest post by Solairis. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
The post In First Activation Meeting, Bitcoin Developers Discuss Paths For Taproot appeared first on Bitcoin Magazine.
Leave a Reply