[bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

[bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

[Michael Folkson]

[-- Attachment #1: Type: text/plain, Size: 5482 bytes --]

A summary of the first Taproot activation meeting (February 3rd) is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html


It appears there is one (hopefully) last stumbling block before we are
ready to propose Taproot activation parameters to the mailing list.


Hence we are organizing a follow up meeting on IRC on the
##taproot-activation channel on Tuesday 16th February at 19:00 UTC.


As I said in the summary of the first Taproot activation meeting whether
lockinontimeout (LOT) is set to true or false in a Bitcoin Core release
attracted discussion during the meeting and has continued to attract
discussion afterwards.


I will weigh up the arguments I have seen for both true and false here. I
won’t comment on the strength of the arguments, merely attempt to summarize
them. Any errors are my own.


Arguments for setting lockinontimeout (LOT) to true in a Core release

T1) This entirely eradicates the possibility (however unlikely) that
Taproot fails to activate within a year. Although approximately 90 percent
of mining pools have already pledged to activate Taproot there is no reason
to open the door to possible delays and political shenanigans for no
reason, however unlikely.

T2) Given users can change LOT=true at any point (and some have declared
they will be setting LOT=true regardless), setting LOT=false in Core opens
up edge case scenarios where different proportions of users on the network
change to LOT=true at different points in time in an uncoordinated fashion.
Given the end state we all want is Taproot activated it doesn’t make sense
to open the door to these edge cases. Setting LOT=true in Core would mean
there is no motivation for users to change LOT in the software they are
running.

T3) We should not be putting users in a place where they feel they need to
change LOT. The urge to change LOT will be strong if miners delay for an
unreasonable period. We are then in a situation where a decision has to be
made on whether Core releases a new version with LOT=true and this whole
discussion kicks off again. We should definitely seek to avoid the need to
rehash this discussion later in the year.

T4) LOT is only relevant if miners fail to activate. It doesn’t make sense
to set it to false as that is essentially saying if miners fail to activate
early, LOT should also let them not activate.

T5) Activation should only be attempted once community consensus for the
soft fork has been reached. Miner signaling is not voting for the changes,
it is signaling readiness. There is no reasonable rationale for not being
ready within a year.

T6) An argument belcher outlined on IRC. If LOT was set to true and a chain
split happened then the Taproot chain doesn’t have wipeout risk so there’s
a really strong incentive to be on the Taproot activating LOT=true chain
and therefore using LOT=true means the risk of a chain split is actually
lower.



Arguments for setting lockinontimeout (LOT) to false in a Core release

F1) The probability of Taproot not being activated by miners is small. This
is not 2017, this is not SegWit, there is no need to worry.

F2) The worst case scenario is we have to wait over a year for Taproot to
be activated. Even the worst case scenario is not a disaster.

F3) If in the unlikely scenario miners did not activate Taproot for a year
for no apparent reason we would never set LOT to false again for any
potential future soft fork. If miners fail to activate Taproot despite
pledging support and there being overwhelming community consensus for it,
it would set a precedent that miners cannot be relied upon *at all* to
activate soft forks.

F4) If in the highly unlikely scenario that a bug or some problem with the
Taproot implementation was found during the signaling period miners could
choose not to activate it which is cleaner than needing an emergency Core
release.


Then some additional arguments nullc posted on Reddit

https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/

F5) LOT = false is more similar to what was done previously (unless you go
way back to the earliest soft forks which were more similar to LOT = true)

F6) It is more important that no rules that harm users are deployed than it
is that new useful rules are deployed quickly. If there is a choice between
“faster” and “more clear that this isn’t a mechanism to force bad things on
users” we should prefer the latter. Plenty of people just don’t like
LOT=true very much absent evidence that miners are blocking deployment. To
some it just feels needlessly antagonistic and distrusting towards part of
our community.


There are some additional parameters other than LOT we will discuss in this
meeting such as activation threshold, start time etc but personally I don’t
think they will attract the same discussion as LOT.


As I’ve stated before please continue to engage productively and in good
faith. I can see arguments with merit on both sides of the LOT discussion
but there appears to be overwhelming consensus that Taproot is activated
this year and there appears to be no reason it shouldn’t be. This
discussion on LOT really should not derail that.

-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

[-- Attachment #2: Type: text/html, Size: 12366 bytes --]

Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

[David A. Harding]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

On Fri, Feb 05, 2021 at 12:43:57PM +0000, Michael Folkson via bitcoin-dev wrote:
> https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
> [...] 
> F6) It is more important that no rules that harm users are deployed
> than it is that new useful rules are deployed quickly. If there is a
> choice between “faster” and “more clear that this isn’t a mechanism to
> force bad things on users” we should prefer the latter. Plenty of
> people just don’t like LOT=true very much absent evidence that miners
> are blocking deployment. To some it just feels needlessly antagonistic
> and distrusting towards part of our community.

I think F6, above, bundles together several of Maxwell's points and
maybe loses something in summary.  I'd encourage interested readers to
view the original post that Folkson referenced.  I'd like to extract one
part as a separate point and write about it a bit in my own words:

F7) defaulting to LOT=false makes non-activation possible even if people
    run the code that developers provide, meaning a successful
    activation proves that at least some people (e.g. miners or UASFers)
    voluntarily took actions that were well outside the scope of
    developer control.

    This makes it clear that developers don't control changes to the
    system.  There are other arguments that demonstrate that developers
    aren't in control[1], but they aren't as clear as simply pointing
    out that a rule change won't go into effect until at least several
    non-developers independently act of their own accord.

    Having such a clear argument that developers aren't in control
    bolsters the decentralized ethos of Bitcoin and reduces the chance
    that bad actors will pressure Bitcoin developers to attempt future
    unwanted changes.  

-Dave

[1] IMO, the main evidence we have that developers aren't in control of
    the system is that Bitcoin Core is free software which gives anyone
    who obtains a copy of it the legal right to run it, learn from it,
    modify it, and share additional copies of it for any purpose.  Each
    time someone uses those rights to create alternative Bitcoin
    implementations, altcoins, or forkcoins, they demonstrate that users
    could change the system---or resist changes to it---in opposition to
    the current developer team, should that become necessary.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

[Luke Dashjr]

Answering the F1-F7 arguments for LOT=False...

> F1) The probability of Taproot not being activated by miners is small. This
> is not 2017, this is not SegWit, there is no need to worry.

While we believe miners have no reason to sabotage Taproot activation, this 
was also the belief leading up to Segwit’s activation in 2017, and regardless 
it is not desirable to create such a risk forcing the community to place 
extra trust in miners. Miners might very well not exploit an inflation bug, 
but that is no reason to purposefully add an inflation bug.

> F2) The worst case scenario is we have to wait over a year for Taproot to
> be activated. Even the worst case scenario is not a disaster.

While it is true that a second activation can be deployed in the event of the 
first one failing, doing so would not necessarily change the situation unless 
LOT were changed to true anyway - in which case, it might as well be true for 
the initial deployment as well. Furthermore, a re-deployment could create a 
situation where users believe they have already upgraded for Taproot, but do 
not enforce it due to not understanding the need to upgrade yet again.

> F3) If in the unlikely scenario miners did not activate Taproot for a year
> for no apparent reason we would never set LOT to false again for any
> potential future soft fork. If miners fail to activate Taproot despite
> pledging support and there being overwhelming community consensus for it,
> it would set a precedent that miners cannot be relied upon *at all* to
> activate soft forks.

Setting LOT=false with a threat to change it to true later is antagonistic 
against miners. With LOT=true, expectations are simply made clear and miners 
can simply cooperate by making valid blocks as they do day-to-day already.

> F4) If in the highly unlikely scenario that a bug or some problem with the
> Taproot implementation was found during the signaling period miners could
> choose not to activate it which is cleaner than needing an emergency Core
> release.

The risk that a bug in Taproot is discovered this late yet before activation, 
to warrant aborting the deployment, is extremely low (much lower than the 
risks created by LOT=false). Even if such a scenario occurred, and even with 
LOT=false, users would still need to upgrade to back out the deployment. In 
the best-case scenario, users would need to upgrade to deploy the fixed 
Taproot. So in the end, nothing is to be gained from relying on a miner abort 
for such scenarios.

> F5) LOT = false is more similar to what was done previously (unless you go
> way back to the earliest soft forks which were more similar to LOT = true)

The behaviour of LOT=false has proven problematic and caused failure of Segwit 
activation in 2017. LOT=true behaviour has a long history of success, and was 
used to resolve and activate Segwit in 2017 after LOT=false’s failure.

> F6) It is more important that no rules that harm users are deployed than it
> is that new useful rules are deployed quickly. If there is a choice between
> “faster” and “more clear that this isn’t a mechanism to force bad things on
> users” we should prefer the latter. Plenty of people just don’t like
> LOT=true very much absent evidence that miners are blocking deployment. To
> some it just feels needlessly antagonistic and distrusting towards part of
> our community.

Any deployment, or even status quo, can be falsely portrayed/spun in a way to 
harm Bitcoin. As such, only objective criteria should be considered.

BIP 8 makes it explicitly easy for people to reject the softfork if they don't 
like it, so any claim of being "forced" is a non-starter to an honest person.

> F7) defaulting to LOT=false makes non-activation possible even if people
>     run the code that developers provide, meaning a successful
>     activation proves that at least some people (e.g. miners or UASFers)
>     voluntarily took actions that were well outside the scope of
>     developer control.
>
>     This makes it clear that developers don't control changes to the
>     system.  There are other arguments that demonstrate that developers
>     aren't in control[1], but they aren't as clear as simply pointing
>     out that a rule change won't go into effect until at least several
>     non-developers independently act of their own accord.
>
>     Having such a clear argument that developers aren't in control
>     bolsters the decentralized ethos of Bitcoin and reduces the chance
>     that bad actors will pressure Bitcoin developers to attempt future
>     unwanted changes.

Even if developers release software, it must still be accepted by the 
community in the form of actively choosing to run the software which includes 
the activation. So long as the activation is clearly and prominently 
documented, users have taken the action to accept the protocol change. 
Furthermore, the community has already demonstrated a clear and undisputed 
support for the activation of Taproot. If there was/is any question of 
whether that is true or not, it is premature to be planning activation of ANY 
type.

Luke