From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 174F2C000A for ; Tue, 6 Apr 2021 14:51:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 0FD72849D0 for ; Tue, 6 Apr 2021 14:51:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 I8wHot7ntSm5 for ; Tue, 6 Apr 2021 14:51:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by smtp1.osuosl.org (Postfix) with ESMTPS id AD0EB849CE for ; Tue, 6 Apr 2021 14:51:34 +0000 (UTC) Received: from mail-pg1-f182.google.com ([209.85.215.182]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MLvf0-1lUsRd19fI-007lXv for ; Tue, 06 Apr 2021 16:51:33 +0200 Received: by mail-pg1-f182.google.com with SMTP id b17so6882522pgh.7 for ; Tue, 06 Apr 2021 07:51:33 -0700 (PDT) X-Gm-Message-State: AOAM531fYx1/JneaDFR2ASFjx0nc7vzIAVhfgZ8TyM4fiRgWOWrazN9a X7jeC1OUeTaEh9N49ydP1vcS57JcvwtOzSK8vfk= X-Google-Smtp-Source: ABdhPJy6HFSavXAXNNa5l1rh6zZpJ9leIWgz/eW/06BK00msbDZy+0UpBm/CdivIbX69wbHhBaORPyjL4YVEh12Bkr4= X-Received: by 2002:aa7:824e:0:b029:20a:3a1:eeda with SMTP id e14-20020aa7824e0000b029020a03a1eedamr27612840pfn.71.1617720692461; Tue, 06 Apr 2021 07:51:32 -0700 (PDT) MIME-Version: 1.0 References: <20210405103452.GA15866@erisian.com.au> In-Reply-To: From: Adam Back Date: Tue, 6 Apr 2021 14:51:21 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:CS/KiPf6LuIIpL81rrZuAgrma4wg/p9bBxTYtM71/VGYhRvsqju fmulr6uTjGs2p/In0DbdW7zmghO0DJw2s6BEnnfjnuD1Mtza3D9B525q82n9iuyccoHBn0h Ico/fgbMmnQyyz0YWJllaidz0FE3TUPziZQLkXTij1f7RUXi73WomFxn/oHlr0Wfh2qpkDU nL2TtGbzfs4zOBt2zBtLw== X-UI-Out-Filterresults: notjunk:1;V03:K0:9oPUhf2Ep4U=:zjAN922Uq1iUjP1dX98qCO VbPRsgdYeYALyGJEmxnXf8jCJcignmh9RjTmGUV/E2foarKECx6s1Y2P7g2Eu9oXCN35tk36Y wfKYEDYXs0iOMA164ioqPckXIEO3HtbOgurcavmgDPwUrdXwS2hy4u8qpu8ZBTLwKytB7yxRd +dTRCbhSPnFV85d+Qj4gpLyAbRKJjIIYzVm8eEfxqq9GKFj12PDxWmSoH+1/SNZtIWQQhr6OI 52B+4TjbZiRPxrhZ01Qm6K7Eb/S0T+IQkPSaSkia+L1XdS3LdL/hUqkH4741OYqePCE193+tR wEEhkFXwuzMxwxo2NAOuezEYcOGEprw4P4AEkk8JtdmYEbWWrpasCqklojek8rY+dDurTr/0o 148gseq6PsL2aLjCoiKQfnWV95yMSQHRNDxAWTtelUBkD/EhW0YjGnAXcWBOMZ1jRBwqP0ir/ BdgKFTxsquhM4nlWr4ZibftJYx3MboLv00NEnd4iaYgpQrcIHFGp X-Mailman-Approved-At: Tue, 06 Apr 2021 15:28:21 +0000 Cc: Anthony Towns Subject: Re: [bitcoin-dev] Taproot Activation Meeting Reminder: April 6th 19:00 UTC bitcoin/bitcoin-dev 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: Tue, 06 Apr 2021 14:51:36 -0000 As I understand Andrew Chow has a patchset for height based activation of Speedy Trial, so that it would be great if people could review that to help increase the review-cycles. Personally I also somewhat prefer block-height based activation, and for myself it seems like a mild step backwards to go back to MTP, when as far as I understand most consider height-based to be a better defined and cleaner, more predictable solution. Adam On Tue, 6 Apr 2021 at 15:35, Russell O'Connor via bitcoin-dev wrote: > > I'm pretty sure that the question of "is signalling still possible by the= time enough miners have upgraded and are ready to start signalling?" Stron= gly benefits from a guaranteed number of signaling periods that height base= d activation offers. Especially for the short activation period of Speedy = Trial. > > The other relevant value of giving enough time for users to upgrade is no= t very sensitive. It's not like 180 days is magic number that going over i= s safe and going below is unsafe. > > That said, as Jeremy has pointed out before (maybe it was on IRC), we can= almost ensure a minimum of 7 retargeting periods by carefully selecting si= gnaling start and end dates to line up in the middle of expected retargetin= g periods that we would otherwise chose with height based activation. Why w= e would rather use MTP to fake a height based activation, I will never unde= rstand. But if this is what it takes to activate taproot, that is fine by m= e. > > The differences between height and MTP activation are too small to matter= that much for what is ultimately transient code. As long as MTP activatio= n can pass code review it is okay with me. > > > On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, wrote: >> >> On Sat, Apr 03, 2021 at 09:39:11PM -0700, Jeremy via bitcoin-dev wrote: >> > As such, the main conversation in this agenda item is >> > around the pros/cons of height or MTP and determining if we can reach = consensus >> > on either approach. >> >> Here's some numbers. >> >> Given a desired signalling period of xxx days, where signaling begins >> on the first retarget boundary after the starttime and ends on the last >> retarget boundary before the endtime, this is how many retarget periods >> you get (based on blocks since 2015-01-01): >> >> 90 days: mainnet 5-7 full 2016-block retarget periods >> 180 days: mainnet 11-14 >> 365 days: mainnet 25-27 >> 730 days: mainnet 51-55 >> >> (This applies to non-signalling periods like the activation/lock in dela= y >> too of course. If you change it so that it ends at the first retarget >> period after endtime, all the values just get incremented -- ie, 6-8, >> 12-15 etc) >> >> If I've got the maths right, then requiring 1814 of 2016 blocks to signa= l, >> means that having 7 periods instead of 5 lets you get a 50% chance of >> successful activation by maintaining 89.04% of hashpower over the entire >> period instead of 89.17%, while 55 periods instead of 51 gives you a 50% >> chance of success with 88.38% hashpower instead of 88.40% hashpower. >> So the "repeated trials" part doesn't look like it has any significant >> effect on mainnet. >> >> If you target yy periods instead of xxx days, starting and ending on a >> retarget boundary, you get the following stats from the last few years >> of mainnet (again starting at 2015-01-01): >> >> 1 period: mainnet 11-17 days (range 5.2 days) >> 7 periods: mainnet 87-103 days (range 15.4 days) >> 13 periods: mainnet 166-185 days (range 17.9 days) >> 27 periods: mainnet 352-377 days (range 24.4 days) >> 54 periods: mainnet 711-747 days (range 35.0 days) >> >> As far as I can see the questions that matter are: >> >> * is signalling still possible by the time enough miners have upgraded >> and are ready to start signalling? >> >> * have nodes upgraded to enforce the new rules by the time activation >> occurs, if it occurs? >> >> But both those benefit from less real time variance, rather than less >> variance in the numbers of signalling periods, at least in every way >> that I can think of. >> >> Corresponding numbers for testnet: >> >> 90 days: testnet 5-85 >> 180 days: testnet 23-131 >> 365 days: testnet 70-224 >> 730 days: testnet 176-390 >> >> (A 50% chance of activating within 5 periods requires sustaining 89.18% >> hashpower; within 85 periods, 88.26% hashpower; far smaller differences >> with all the other ranges -- of course, presumably the only way the >> higher block rates ever actually happen is by someone pointing an ASIC a= t >> testnet, and thus controlling 100% of blocks for multiple periods anyway= ) >> >> 1 period: testnet 5.6minutes-26 days (range 26.5 days) >> 13 periods: testnet 1-135 days (range 133.5 days) >> 27 periods: testnet 13-192 days (range 178.3 days) >> 54 periods: testnet 39-283 days (range 243.1 days) >> 100 periods: testnet 114-476 days (range 360.9 days) >> (this is the value used in [0] in order to ensure 3 months' >> worth of signalling is available) >> 132 periods: testnet 184-583 days (range 398.1 days) >> 225 periods: testnet 365-877 days (range 510.7 days) >> 390 periods: testnet 725-1403 days (range 677.1 days) >> >> [0] https://github.com/bitcoin/bips/pull/1081#pullrequestreview-62193464= 0 >> >> Cheers, >> aj >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev