From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4FBF9C000A for ; Wed, 24 Mar 2021 11:24:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 32053404B1 for ; Wed, 24 Mar 2021 11:24:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 GB3eSa7TndL4 for ; Wed, 24 Mar 2021 11:24:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by smtp2.osuosl.org (Postfix) with ESMTPS id 4B0F4400FC for ; Wed, 24 Mar 2021 11:24:05 +0000 (UTC) Received: by mail-ot1-x32e.google.com with SMTP id g8-20020a9d6c480000b02901b65ca2432cso22639707otq.3 for ; Wed, 24 Mar 2021 04:24:05 -0700 (PDT) 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=G7efmM8fLlsgge9slholov9F3Em3YbjUWZL+ZWfN5Sw=; b=HOvER8cfQntrWM3fPSgE7AoNkyP4MKqvEi3+O3XP1XZ2W+0epRQ6O9goV50v+0dxlz kCJBhHIVIC0iXLuFZ9mZB2X5TX2B0q14kAPbLX6hld6cyjyqtZty+daNeXIaT5pAabnR yRcrGz7+HCRrkPg0rBxxA2bblFkBSm2V0sisv5pVzLENZ1+KA35+gsqQHbeHd1VJ4tTj rOxPNuc/4d2KSfPm6BzJRj5a8PW5yMFU2404lXbNHuaLfv4gULws2Fqt3C1i5kumCOik q7lqHAN6tvSjx6fHxPKdNqBqlcX8LakSTLMgNmpMEZBG8LKmyFLvi7Sta+FvvQ1DkQ7Y mzag== 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=G7efmM8fLlsgge9slholov9F3Em3YbjUWZL+ZWfN5Sw=; b=ff75J7Pumm8VIq55h/JlnP0fxut6y1y90lses42CDwuorkk8ry5UAxpnqoSffDJoZx 7P/xxUjSBGN1dOwbQNM87G1dxLn+3VnNYfx/2fBRc6zqKg/HD9vx6i3XJz3nKHavTVVU iIoW8HOJQNkncbFSIx/9GztSoMVfgthV5pL7EzHbyXJ/GClDpScOZEkHAU7smoinRrwy hEA1a2wSnLhx7cRZY11yM32QkF5pi5aqxCdjkv7eSkTqov28rMeMEO3L4RE1iQ0X84k2 wnkPwkOiakv7VW4bfL0+Zu5VO5Ou+zRgYUF6UAcX+/PIo0xxrYpoIpwagl1rWIieNcuE jmhw== X-Gm-Message-State: AOAM533zX/MKKfQfAxpiI8R5f/DVbhwQj0oCGCC3UnR/RoMZzNYK2zmk mEeXvLcUbBN+3ouszihzWFoOSKN38M4yuQeZmZs= X-Google-Smtp-Source: ABdhPJzj66rHVD3Dp+PQYF+1qHHgcTEMKCGesu36pULE3oV5WUWN9qIOjS4jCd2usixEtyY3GKT74URuPaz/zF6b32g= X-Received: by 2002:a05:6830:2118:: with SMTP id i24mr2823506otc.290.1616585044240; Wed, 24 Mar 2021 04:24:04 -0700 (PDT) MIME-Version: 1.0 From: Michael Folkson Date: Wed, 24 Mar 2021 11:23:53 +0000 Message-ID: To: jlrubin@mit.edu, Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Wed, 24 Mar 2021 11:55:57 +0000 Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes 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: Wed, 24 Mar 2021 11:24:06 -0000 Thanks for this Jeremy. I agree with the vast majority of this. For those that missed yesterday's meeting the meeting log is here: http://gnusha.org/taproot-activation/2021-03-23.log Jeremy also livestreamed the meeting on his Twitch channel: https://www.twitch.tv/videos/960346848 On the choice between using block heights consistently or using a weird mix of both block heights and MTP in the same activation mechanism you can put me down for a NACK for the latter also. In addition I documented here the preferences for a consistent use of block height: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802336038 If it was a direct choice between entirely block height or entirely MTP then I probably wouldn't NACK either. But using a mix of both makes no sense to me. The two arguments in favor of using a weird mix of block heights and MTP appear to be: 1) "additional review required to ensure height based activation" 2) To prevent a "marketed push to launch a UASF client." On 1) I would argue that the additional review required is not excessive by any means and we have the time to review a consistent use of block height (especially if people spent their time reviewing a PR with a consistent use of block height rather than arguing for a mix). On 2) if we are making technical decisions based on speculating on the marketing strategies of other projects Bitcoin Core is a very different project to the project I thought it was. I personally would find it much easier to reason about timings and time intervals of the different activation phases if block heights are used consistently across the activation mechanism rather than a weird mix of both block heights and MTP. Other than that, I agree it was an excellent meeting and thanks for your efforts organizing and hosting the meeting. -- Michael Folkson Email: michaelfolkson@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3