MIME-Version: 1.0
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
 <CAMZUoKkWmdwi-VH3WUvFfG+5MDK3xhvZUac3eBQbxXX_b_btWw@mail.gmail.com>
 <4947b02e-90fb-9044-4552-767de805ff14@mattcorallo.com>
 <CAMZUoKmTL+2GMpv8Qr5uOUC2bMgyuzMPw1zjdjuD+XNE23-65A@mail.gmail.com>
 <CALeFGL2oh5WZi0y64Q0-FjANE8W3GoBrXFNo=9a1OpjcssT30w@mail.gmail.com>
In-Reply-To: <CALeFGL2oh5WZi0y64Q0-FjANE8W3GoBrXFNo=9a1OpjcssT30w@mail.gmail.com>
From: Ryan Grant <bitcoin-dev@rgrant.org>
Date: Fri, 5 Mar 2021 14:51:12 +0000
Message-ID: <CAMnpzfrTkP=9JXHg2+1Xz03q34w-YoB_Nff5trw9OyqOSqB_0A@mail.gmail.com>
To: Keagan McClelland <keagan.mcclelland@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
Precedence: list

On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> So that leads me to believe here that the folks who oppose LOT=true
> primarily have an issue with forced signaling, which personally I
> don't care about as much, not the idea of committing to a UASF from
> the get go.

The biggest disconnect is between two goals: modern soft-fork
activation's "Don't (needlessly) lose hashpower to un-upgraded
miners"; and UASF's must-signal strategy to prevent inaction.

  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html

This question dives to the heart of Bitcoin's far-out future.
Of two important principles, which principle is more important:

  - to allow everyone (even miners) to operate on the contract they
    accepted when entering the system; or

  - to protect against protocol sclerosis for the project as a whole?

Do miners have a higher obligation to evaluate upgrades than economic
nodes implementing cold storage and infrequent spends?  If they do,
then so far it has been implicit.  LOT=true would make that obligation
explicit.