The meeting ended with rough
consensus in favor of BIP8 (false), as well as with approval of two
possible methods to put this BIP into motion.
Many of
Bitcoin’s most active stakeholders have just about nailed down the
activation method for Taproot, the Bitcoin software’s biggest upgrade in
years.
In
a public meeting on Internet Relay Chat (IRC) Tuesday, Bitcoin
developers, miners, business professionals and enthusiasts hashed out
the specifics of how to package the Taproot upgrade into an update – and
how to activate it once the code has been shipped.
The
most active of the 200 or so participants on the chat (mostly, but not
all, developers) seemed to agree on the Bitcoin Improvement Proposal
(BIP) that would be used to activate Taproot. To prep the BIP for
shipment, they also voted to “merge” two “pull requests” (PRs) on GitHub
that outline the rules for Taproot’s activation logic into Bitcoin’s
source code when the time comes to push the upgrade.
One of these, PR #1021, includes a measure to allow users to force activate the upgrade should miners not support it, while PR #1020
only “recommends” this forcing but does not enable it by default. Since
most all participants support BIP 8 without forced activation, as
meeting leader and Bitcoin Core developer Michael Folkson noted in the
chat, further discussion will pinpoint a date to begin activation – and
further discuss the extent to which a “flag day” to force activation is
necessary.
Why a Taproot flag day (probably) isn’t needed
Not that miners blocking the upgrade should be an issue for Taproot, which has some 91% miner support, according to a survey run by F2Pool VP Alejandro De La Torre.
The
survey provides crucial feedback from miners for Bitcoin’s
decentralized organization, which cannot unilaterally coordinate updates
the way a centralized software provider can. Upgrades like Taproot
require painstaking coordination between miners, full-node users (those
running Bitcoin’s open-source code) and other stakeholders to ensure
nothing goes wrong (like introducing a bug or splitting the Bitcoin
network into two incompatible versions).
Because
miners have shown no resistance to Taproot, most participants voiced a
preference for BIP8 (false), with the (false) referring to the exclusion
of a “flag day” to force activation through full nodes should the
upgrade fail through lack of miner activation.
BIP8
as currently devised would give Bitcoin miners and full-node operators a
year to adopt the upgrade, after which point the upgrade would be
“locked in” with enough support. In one version of this, BIP8 (false),
the update simply fails without enough support. In another, BIP8 (true),
a “flag day” would force miners to signal for the upgrade when the
activation time frame expires if they did not do so beforehand.
Technical
note: There are a few ways to upgrade Bitcoin, the easiest being
through miner activation where mining pools upgrade and begin mining
blocks under the new rules. Failing this, node operators can upgrade and
choose to reject blocks from miners who have not signaled support for
an upgrade. This so-called “user activate soft fork” (UASF), also used to activate SegWit, would force holdout miners to adopt the new upgrade.
“Completely anecdotal but I’ve not seen any
[emphasis theirs] opposition to Taproot,” one willcl_ark said in the
chat, referring to whether or not a flag day is necessary. “I think
using the lowest common denominator of activation parameters (false)
seems like the sensible choice to avoid any purposeful or accidental
chain splits in the case miners don’t signal.”
What’s the holdup?
Still
others, like prolific Bitcoin Core developer Luke Dashjr, are not
convinced the inclusion of a flag day is unnecessary. In fact, it’s a
matter of principle to demonstrate that node operators decide software,
not miners.
“It
doesn’t matter,” he said in the chat in reference to miner support.
“Miners do not decide protocol changes,” he continued, intimating that
it’s the node operators who decide instead by choosing what software to
run. Further, he espoused that BIP8 (false), “let[s] miners decide” the
fate of the upgrade. When the time comes, he said later in the chat, he
will configure his node to run the BIP8 (true) version that rejects
non-Taproot blocks from miners.
“BIP8
with mandatory [activation] is not an unnecessary show of force,” said
hsjoberg, reiterating Dashjr’s belief that the user-choice of a UASF is a
necessary check and balance on miner apathy.
Still,
a show of force could introduce unnecessary risk and set an unwelcome
precedent for future upgrade deliberations, especially when miners have
given users no reason to be combative, so go the arguments in favor of
BIP8 (false).
“[BIP8
false] is safer than [true], so it’s worth doing [false] first given
that we know hashpower is ~90% already pro-Taproot,” Bitcoin Core and
CoinSwap developer Chris Belcher said.
Others
like Suredbits and Bitcoin Core developer Ben Carman pointed out that
you could configure the upgrade later on into activation to include the
flag day should miners fail to signal, “making it safer and easy for
users to enforce the UASF.”
At
the end of the meeting, the participants agreed to merge pull requests
on GitHub for both a non-forced activation route (PR #1020) and a forced
activation route (PR #1021). With both of these rules in Bitcoin Core’s
GitHub, the rules for a forced activation could be used only if
necessary.
More deliberation
The
chain split scenario that willcl_ark described is basically the
bogeyman everyone wants to avoid here. The fear is that BIP8 (true)
requires 100% of hashrate to signal for the upgrade after the Taproot
activation deadline ends. Thus, if enough users went this route at the
same time that others use BIP8 (false) for non-forced activation (which
only requires 95% of hashrate), the two different code versions may
create two incompatible histories of Bitcoin’s transaction ledger.
That’s
why, if forced signalling must happen at all, it’s best to do so
through AJ Townes’ PR #1021, which “makes it safer for the UASF option
which is the most ‘dangerous’ scenario,” Carman wrote in the chat.
For
now it seems as if those involved in discussions favor BIP8 (false)
with the addition of a UASF through PR #1021 if needed, but further
discussion is needed to hammer out the exact timeline of the initial
activation period (or how long users have to upgrade after the update
goes live), as well as what activation date to set.
These “what ifs” and “whens” will be hashed out, among other matters, in a meeting next Wednesday.
source link: https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update
