From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 328F2C0733 for ; Fri, 17 Jul 2020 02:58:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 1BF878618D for ; Fri, 17 Jul 2020 02:58:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5av3OiDtEoC for ; Fri, 17 Jul 2020 02:58:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 4ABC18616A for ; Fri, 17 Jul 2020 02:58:53 +0000 (UTC) Date: Fri, 17 Jul 2020 02:58:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1594954731; bh=PmPVRHDTsPEQD57FEIxSeYeEC8/s558lpvfYU7sLQNc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=VHV511CYWrvbk6ZwFCMNTHvMAxfrfiPnXU8B6w6g2VVG5us+wNx+kN7qoYCJvIWXl mhPYrwJphSwYjk9YKhJPs/BJyoBBanNxEJ6zRHBDtqyeqlyQgBS3UMITE0T/wC2Vz5 ijBO2aQ5m4ekW8gHU1LzYta8Fjl3sF+KlfM29CAI= To: Matt Corallo , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <9c401353-d63a-3d19-72a8-ffcaf169ac6d@mattcorallo.com> References: <20200714093730.myvls2jfpwyi3ap3@erisian.com.au> <9c401353-d63a-3d19-72a8-ffcaf169ac6d@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Thoughts on soft-fork activation 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, 17 Jul 2020 02:58:55 -0000 Good morning list, BlueMatt and aj, There is an idea circulating on IRC and elsewhere, which seems to be at lea= st mildly supported by gmax and roconnor, which I will try to explain here. (These are my words, so if there is some mistake, I apologize) Basically: * Deploy a BIP8 `lockinontimeout=3Dtrue` `lockin=3D+42 months` (or 36 month= s, or 24 months) at next release. * Pedanty note: BIP8 uses blockheights, not actual times. * Then 1 year after `starttime`, ***if*** it is not activated yet: * Discuss. * If we think it is only because of miner apathy and user support seems g= ood regardless, deploy a BIP91 reduced-threshold 80% that enforces the BIP8= bit. * We hope that this will stave off independent attempts at a UASF with = a faster timeout. * If we think there are real reasons not to continue with Taproot as-is, = deploy an abort: a softfork that disallows transaction outputs with `OP_1 <= 32-bytes>` `scriptPubKey` (other lengths and other versions are allowed). This approximates what aj is proposing: * Ultimately, we expect to deploy a BIP8 `lockinontimeout=3Dtrue` that will= have a timeout that ends +42 months after the first countdown, even with M= odern Softfork Activation. * The abort is roughly equivalent to the Modern Softfork Activation case wh= ere during the 6 month discussion period we decide not to deploy Taproot af= ter all. * The deployment of a BIP91 reduced-threshold 80% approximates what aj prop= oses, to reduce the threshold for activation later. As I understand it, an advantage of this proposal is that we can deploy ver= y quickly a relatively simple BIP8 `locktimeontimeout=3Dtrue`, then continu= e debate on various details (is 80% too low? too high? are users actually d= eploying? are mining pools updating? etc) in parallel. This lets the code into the hands of users where they can start deploying i= t and we can start getting better gauges on how well Taproot is supported. Regards, ZmnSCPxj