Luke Dashjr [ARCHIVE] on Nostr: đź“… Original date posted:2021-02-28 đź“ť Original message:Answering the F1-F7 ...
đź“… Original date posted:2021-02-28
đź“ť Original message: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
đź“ť Original message: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