From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 619CBC0001 for ; Sat, 27 Feb 2021 17:37:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 3203A433A5 for ; Sat, 27 Feb 2021 17:37:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctkMEUHZ8EYk for ; Sat, 27 Feb 2021 17:37:05 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by smtp2.osuosl.org (Postfix) with ESMTPS id 607AD4343D for ; Sat, 27 Feb 2021 17:37:04 +0000 (UTC) Received: by mail-oi1-f182.google.com with SMTP id j1so13452559oiw.3 for ; Sat, 27 Feb 2021 09:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/SlJTn788F7WZQXL4Q3D82c4ohPH3EkHKGsoiKx/rDw=; b=j309ittttnaSsCrrrl2ZNeaOIMPDKNCT+U3J3gij3IwbaT/oI8STgNsVgDUz67LlEa 8lQ+LCCiba1pGjYJaMYp6DyX5JFRmOgk+q9g/3ylneGjjYwv4nB+/jFJHVIZdXjNoNzd f+GpgbEOpZ/Xb4aX2O+qvBErMufJnixfsZeCzVsoADcu8keWwqYDzdxe8obxnEyHVu32 hGkrLAzltNrRg50AsUs81Q4VrHPBKlCN95QrmF+BVgaABvurMtNfJj2penRunPYx5Dks Vr+H75xUpKy/wtQbwP+Eo2jnpzwMpfWWIqLXrCl7wrKaL4pY2FKl7hy4HNRbqvEHh6n1 GkUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/SlJTn788F7WZQXL4Q3D82c4ohPH3EkHKGsoiKx/rDw=; b=LJK+p3KTziK8qj9VmqyNm64zg6zrenpAq9HFDLm61RAFsbXiQLzu93B+fR67/M7Xmu wVSdZiPZSVjwr+dXH6AWjuKtNGK3JHHDlFSM1q3x4YNKC2m2lCeODzx1I0hqZOkCF5L2 rhKLpo7W0cmIIN9VKuH26kGTmotTU2R4yR21JJVohGzgHBg32FBNoFvZMzleaQDkpU5J CZpEn/MBhsmEt4WYkhWEpDLHGvJ0Ke/lQoyPwnnAeHvmkrkClhnPysRbU/neOqfsB1Qf Db9sEwYFGvRxWaWQOQSa09Y8nwf3NwKihvbth6uqUnxVQmEzAIdumBTNNj+Dzxdv8OSG ydeQ== X-Gm-Message-State: AOAM5317kXeMlauow0iVNe12bD54uX3ZIGpAPSd+eDYLQ5c5Yqb23V3j 4w/WcyzR8y/ngyhmfPCEUCqMrmBH4U9lWsauopJIOrMbG1M= X-Google-Smtp-Source: ABdhPJzNFozXMRpJJakkupfmldaSRe1DXbsUNeCuxDuE0V6rJ8eSxYJz6IUUP3640bpJ2YCLi3Bvt1rLZjhSOdRFWf4= X-Received: by 2002:aca:aa96:: with SMTP id t144mr6305122oie.131.1614447423049; Sat, 27 Feb 2021 09:37:03 -0800 (PST) MIME-Version: 1.0 From: Michael Folkson Date: Sat, 27 Feb 2021 17:36:51 +0000 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sat, 27 Feb 2021 20:55:30 +0000 Subject: [bitcoin-dev] Taproot activation facts on lockinontimeout (LOT) 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: Sat, 27 Feb 2021 17:37:06 -0000 I just want to lay out some facts as I see them because frankly I feel any personal opinion is irrelevant at this point and without agreement on facts we are going round in circles. I end with a personal opinion which you can feel free to ignore. 1) There is a long list of current and past Core contributors who have said they effectively NACK setting a default of lot=true in Core. There are a small number of current and past Core contributors who have said they effectively NACK setting a default of lot=false in Core. If Core sets a default (barring an incredible transformation in views) the only default that is possible at this stage is lot=false. 2) Core forcing users to choose lot=true or lot=false before they can use the software is not viable, nor is it a good idea. This suggestion was withdrawn by ZmnSCPxj. 3) There has been an idea floated (by Rusty and Greg amongst others) of setting a config option such that users could (easily or with greater difficulty) change the default set in Core to their preferred option. Nobody as far as I'm aware is coding this up and intending to open a PR to do this currently. Bitcoin Core pull requests are open to anybody and this may change. 4) There is a non-Core project (https://github.com/BitcoinActivation/bitcoin) that plans to release lot=true as a default. If this is coded up and anyone runs this software there will be lot=true nodes on the network regardless of what Core does. 5) Core could (in theory) not release any activation code, either because there is no consensus on the lot default or out of concern for a (possible but unlikely) chain split if miners failed to activate for a year. If Core chooses to not release anything Taproot will only activate if users and miners run non-Core software. **Personal opinion (feel free to ignore)** Assuming these facts (feel free to correct me if you think any of the above aren't facts) I will put forward a personal opinion. Core releasing nothing and putting all users (including miners) in a position where the only way they can activate Taproot is to run non-Core software seems to me to be highly suboptimal. I do appreciate that if Core releases a default of lot=false that there is a small but non-zero risk of a chain split *if and only if* miners fail to activate within a year. Soft forks are not 100 percent risk free. If the community's appetite for risk and disruption is literally zero we should not attempt to activate Taproot. I would argue the long term benefits for the ecosystem of Taproot *significantly* outweigh that non-zero downside risk. -- Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3