From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4B21EC0001 for ; Fri, 5 Mar 2021 14:51:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 31800844DE for ; Fri, 5 Mar 2021 14:51:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrebcdq50axM for ; Fri, 5 Mar 2021 14:51:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by smtp1.osuosl.org (Postfix) with ESMTPS id 275B9844DD for ; Fri, 5 Mar 2021 14:51:39 +0000 (UTC) Received: by mail-wm1-f53.google.com with SMTP id i9so1692357wml.0 for ; Fri, 05 Mar 2021 06:51:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=itU3zeExUwsO0hrWiobHM5ZoKetjdmBPVvnP7Sf1nWE=; b=b3WL6Onsk0cyHFs3VEtsgIcDmgkQTzbXelhCHGNUOojgCZluii056ByxIGoGQ50koG eR5ZBkjOM1plNaEzrtuxOhkhT00F0UAlft9BOvGbSbpozPdQKzm1NYSosD4Oo552Ed4O KsWsyxvnIUpovcC6tqUyPqC6ZEQoHu93pJ5IB9RA7YsqcHm02aOX3YmF5CawYqWL1zye dmdHKeaodizYQBRigkM5JxTt8oI/GbF4qz7NPSSrIzUfwzCkZq0PbsYW1vOsmUXESLju UV18btAEUfFX+e+hOz7s3mcopqT0T5HSC7JiEzdwzkz4oBPaiSphDZLO7CYJRfoi+oDA PjGg== X-Gm-Message-State: AOAM5325+rzZG7YwIoqXPGZjBCg0+K3jApLVH87bsKH4KbxZmo60I4gq bVoBREgjDVBlTzdplXTxGBUKGpR8HLHLbyUjcwcL+Q== X-Google-Smtp-Source: ABdhPJyGunxf0PlZhZl/kl3pIGaZEi3PujB6qGaPJeEzpFWJHxDg8tidH2UuJQPQ6jMUm6dhnKM8ezLdaxv4ggOPCt8= X-Received: by 2002:a1c:dc42:: with SMTP id t63mr9256475wmg.153.1614955898295; Fri, 05 Mar 2021 06:51:38 -0800 (PST) MIME-Version: 1.0 References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net> <4947b02e-90fb-9044-4552-767de805ff14@mattcorallo.com> In-Reply-To: From: Ryan Grant Date: Fri, 5 Mar 2021 14:51:12 +0000 Message-ID: To: Keagan McClelland , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2021 14:51:41 -0000 On Thu, Mar 4, 2021 at 7:32 PM Keagan McClelland via bitcoin-dev 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.