Ryan Grant [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-06 📝 Original message:On Tue, Apr 6, 2021 at ...
📅 Original date posted:2021-04-06
📝 Original message:On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The core question always was: what do we do if miners fail to activate?
>
> [...] Speedy Trial takes the approach that "let's pretend we didn't
> *actually* ask [miners]".
What ST is saying is that a strategy of avoiding unnecessary risk is
stronger than a strategy of brinkmanship when brinkmanship wasn't
our only option. Having deescalation in the strategy toolkit makes
Bitcoin stronger.
> It's totally a political approach, to avoid facing the awkward question.
> Since I believe that such prevaricating makes a future crisis less
> predictable, I am forced to conclude that it makes bitcoin less robust.
LOT=true does face the awkward question, but there are downsides:
- in the requirement to drop blocks from apathetic miners (although
as Luke-Jr pointed out in a previous reply on this list they have
no contract under which to raise a complaint); and
- in the risk of a chain split, should gauging economic majority
support - which there is zero intrinsic tooling for - go poorly.
> Personally, I think the compromise position is using LOT=false and
> having those such as Luke and myself continue working on a LOT=true
> branch for future consideration. It's less than optimal, but I
> appreciate that people want Taproot activated more than they want
> the groundwork future upgrades.
Another way of viewing the current situation is that should
brinkmanship be necessary, then better tooling to resolve a situation
that requires brinkmanship will be invaluable. But:
- we do not need to normalize brinkmanship;
- designing brinkmanship tooling well before the next crisis does
not require selecting conveniently completed host features to
strap the tooling onto for testing; and
- it's already the case that a UASF branch can be prepared along
with ST (ie. without requiring LOT=false), although the code is a
bit more complex and the appropriate stopheight a few blocks later.
Although your NACK is well explained, for the reasons above I am
prepared to run code that overrides it.
📝 Original message:On Tue, Apr 6, 2021 at 11:58 PM Rusty Russell via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The core question always was: what do we do if miners fail to activate?
>
> [...] Speedy Trial takes the approach that "let's pretend we didn't
> *actually* ask [miners]".
What ST is saying is that a strategy of avoiding unnecessary risk is
stronger than a strategy of brinkmanship when brinkmanship wasn't
our only option. Having deescalation in the strategy toolkit makes
Bitcoin stronger.
> It's totally a political approach, to avoid facing the awkward question.
> Since I believe that such prevaricating makes a future crisis less
> predictable, I am forced to conclude that it makes bitcoin less robust.
LOT=true does face the awkward question, but there are downsides:
- in the requirement to drop blocks from apathetic miners (although
as Luke-Jr pointed out in a previous reply on this list they have
no contract under which to raise a complaint); and
- in the risk of a chain split, should gauging economic majority
support - which there is zero intrinsic tooling for - go poorly.
> Personally, I think the compromise position is using LOT=false and
> having those such as Luke and myself continue working on a LOT=true
> branch for future consideration. It's less than optimal, but I
> appreciate that people want Taproot activated more than they want
> the groundwork future upgrades.
Another way of viewing the current situation is that should
brinkmanship be necessary, then better tooling to resolve a situation
that requires brinkmanship will be invaluable. But:
- we do not need to normalize brinkmanship;
- designing brinkmanship tooling well before the next crisis does
not require selecting conveniently completed host features to
strap the tooling onto for testing; and
- it's already the case that a UASF branch can be prepared along
with ST (ie. without requiring LOT=false), although the code is a
bit more complex and the appropriate stopheight a few blocks later.
Although your NACK is well explained, for the reasons above I am
prepared to run code that overrides it.