From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 81B3CC0001 for ; Mon, 15 Mar 2021 02:53:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 705BD6F4A4 for ; Mon, 15 Mar 2021 02:53:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dashjr.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHInJZ74x-bJ for ; Mon, 15 Mar 2021 02:53:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp3.osuosl.org (Postfix) with ESMTP id D6AB56F49F for ; Mon, 15 Mar 2021 02:53:08 +0000 (UTC) Received: from ishibashi.lan (unknown [12.190.236.207]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 6D8EE38A00AC; Mon, 15 Mar 2021 02:51:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1615776785; bh=g3lNhGnTH1BakWcgaPpowfApkKT0Vh4gbiJ5eDDgUzc=; h=From:To:Subject:Date:References:In-Reply-To; b=c/mJUE9iwhf+2kDRc0IfcVcQnHEazplmT1gpbE7VJveWADrVCaoL8VTeItuTnATuW BDMIseo1ee4lP0qlw0Q1SQHUTqX7WdECTYmBy8QeqFtBbm4cw8hFcXlUrFFyUz4jNH Re6BBnORq9AHXvYyVEvNYN/4MO/C4C1Ti7ZVaL60= X-Hashcash: 1:25:210315:bitcoin-dev@lists.linuxfoundation.org::WgWmJ0fJB/=zJ4qa:lv3U X-Hashcash: 1:25:210315:achow101-lists@achow101.com::VpFtRpMcNmhg5H/u:e6Ssc From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Andrew Chow Date: Mon, 15 Mar 2021 02:51:46 +0000 User-Agent: KMail/1.9.10 References: <20210306034343.fhwrxmq6gbb2os5m@ganymede> <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com> In-Reply-To: <5be46169-8f38-da73-4112-fba2aff6dfcb@achow101.com> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <202103150251.46902.luke@dashjr.org> Subject: Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial" 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: Mon, 15 Mar 2021 02:53:10 -0000 The last period before timeoutheight here overlaps with the current BIP8(True) deployment plan. So if this period specifically were to reach 90% signalling, nodes would activate Taproot at height 697536, but ST-only nodes would still wait until 709632 instead. Probably the best solution is to just move this ST window 1 period earlier? Luke On Saturday 06 March 2021 06:04:22 Andrew Chow via bitcoin-dev wrote: > I like this idea. > > In terms of actual parameters, I propose that we base this Speedy Trial > off of BIP 8 with the following parameters: > * start height = 681408 > * timeout height = 695520 > * lockinontimeout = False > * signaling bit = 2 > * threshold = 1815/2016 blocks (90%) > > For the extended lockin period, I propose 14112 blocks, which is 7 > retarget periods. Thus the earliest activation height will be 697536 and > the latest activation height will be 709632. > > This will give us an approximate start time of May 1st 2021 and an > approximate timeout time of August 7th 2021, for a total activation > period of just over 3 months. The extended lockin period is the same > number of blocks as the activation period so that will also be just over > 3 months, giving us the latest activation time of November 13th, 2021. > If miners activated as soon as possible, the earliest activation time > would be August 21st 2021. > > Additionally, this timeline assumes a mid-April release of Bitcoin Core > 0.21.1 containing these parameters. They could be changed to move up if > the expected release date were sooner. > > > Andrew Chow > > On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote: > > On the ##taproot-activation IRC channel, Russell O'Connor recently > > proposed a modification of the "Let's see what happens" activation > > proposal.[1] The idea received significant discussion and seemed > > acceptable to several people who could not previously agree on a > > proposal (although this doesn't necessarily make it their first > > choice). The following is my attempt at a description. > > > > 1. Start soon: shortly after the release of software containing this > > proposed activation logic, nodes will begin counting blocks towards > > the 90% threshold required to lock in taproot.[2] > > > > 2. Stop soon: if the lockin threshold isn't reached within approximately > > three months, the activation attempt fails. There is no mandatory > > activation and everyone is encouraged to try again using different > > activation parameters. > > > > 2. Delayed activation: in the happy occasion where the lockin threshold > > is reached, taproot is guaranteed to eventually activate---but not > > until approximately six months after signal tracking started. > > > > ## Example timeline > > > > (All dates approximate; see the section below about BIP9 vs BIP8.) > > > > - T+0: release of one or more full nodes with activation code > > - T+14: signal tracking begins > > - T+28: earliest possible lock in > > - T+104: locked in by this date or need to try a different activation > > process - T+194: activation (if lockin occurred) > > > > ## Analysis > > > > The goal of Speedy Trial is to allow a taproot activation attempt to > > either quickly succeed or quickly fail---without compromising safety in > > either case. Details below: > > > > ### Mitigating the problems of early success > > > > New rules added in a soft fork need to be enforced by a large part of > > the economy or there's a risk that a long chain of blocks breaking the > > rules will be accepted by some users and rejected by others, causing a > > chain split that can result in large direct losses to transaction > > receivers and potentially even larger indirect losses to holders due to > > reduced confidence in the safety of the Bitcoin system. > > > > One step developers have taken in the past to ensure widespread adoption > > of new consensus rules is programming in a delay between the time > > software with those rules is expected to be released and when the > > software starts tracking which blocks signal for activation. For > > example: > > > > Soft fork | Release | Start | Delta > > -----------------+------------+------------+---------- > > BIP68 (v0.12.1) | 2016-04-15 | 2016-05-11 | 26 days > > BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days > > > > Sources: BitcoinCore.org, > > https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc > > > > Speedy Trial replaces most of that upfront delay with a backend delay. > > No matter how fast taproot's activation threshold is reached by miners, > > there will be six months between the time signal tracking starts and when > > nodes will begin enforcing taproot's rules. This gives the userbase even > > more time to upgrade than if we had used the most recently proposed start > > date for a BIP8 activation (~July 23rd).[2] > > > > ### Succeed, or fail fast > > > > The earlier version of this proposal was documented over 200 days ago[3] > > and taproot's underlying code was merged into Bitcoin Core over 140 days > > ago.[4] If we had started Speedy Trial at the time taproot > > was merged (which is a bit unrealistic), we would've either be less than > > two months away from having taproot or we would have moved on to the > > next activation attempt over a month ago. > > > > Instead, we've debated at length and don't appear to be any closer to > > what I think is a widely acceptable solution than when the mailing list > > began discussing post-segwit activation schemes over a year ago.[5] I > > think Speedy Trial is a way to generate fast progress that will either > > end the debate (for now, if activation is successful) or give us some > > actual data upon which to base future taproot activation proposals. > > > > Of course, for those who enjoy the debate, discussion can continue while > > waiting for the results of Speedy Trial. > > > > ### Base activation protocol > > > > The idea can be implemented on top of either Bitcoin Core's existing > > BIP9 code or its proposed BIP8 patchset.[6] > > > > - BIP9 uses two time-based[7] parameters, starttime and timeout. Using > > these values plus a time-based parameter for the minimum activation > > delay would give three months for miners to activate taproot, but some > > of that time near the start or the end might not be usable due to > > signals only being measured in full retarget periods. However, the > > six month time for users to upgrade their node would be not be > > affected by either slow or fast block production. > > > > BIP9 is already part of Bitcoin Core and I think the changes being > > proposed would be relatively small, resulting in a small patch that > > could be easy to review. > > > > - BIP8 uses two height-based parameters, startheight and timeoutheight. > > Using height values would ensure miners had a certain number of > > retarget periods (6) to lock in taproot and that there'd be a certain > > number of blocks (about 24,000) until activation, although latest lock > > in and expected activation could occur moderately earlier or later > > than the estimated three and six months. > > > > BIP8 would likely be used if Speedy Trial fails, so it could be > > advantageous to base this proposal on BIP8 so that we gain > > experience running that code in production. > > > > For additional discussion about using times versus heights, see today's > > log for ##taproot-activation.[11] > > > > ### Additional concerns > > > > - Encourages false signaling: false signaling is when miners signal > > readiness to enforce rules that their nodes don't actually support. > > This was partially responsible for a six-block reorg shortly after the > > final BIP66 activation[8] and was found to still be a problem during > > the BIP68 lockin period despite BIP9 being designed to avoid it.[9] > > > > Because Speedy Trial only gives miners a maximum of three months to > > signal support for taproot, it may encourage such false signaling. If > > taproot locks in as a result of their signaling but most of them fail > > to upgrade by the activation date several months later, unprepared > > miners could lose large amounts of money and users could see long > > reorgs (with unupgraded nodes and SPV lite clients potentially losing > > money). > > > > Compared to other activation proposals, I think the only difference is > > Speedy Trial's short timeline. False signaling is possible with any > > other proposal and the same problems can occur if miners fail to > > upgrade for any mandatory activation. > > > > ### Additional advantages > > > > - No mandatory signaling: at no time are miners required to signal by > > Speedy Trial. This includes no mandatory signaling during the > > locked_in period(s), although such signaling will be encouraged (as it > > was with BIP9[10]). > > > > - Party time: to a lesser degree, a benefit mentioned for flag day > > activation may also apply here: we could get up to six months > > advanced notice of taproot activation, allowing users, developers, and > > organizations to prepare software, announcements, and celebrations for > > that event. > > > > ## Implementation details and next steps > > > > Initial discussion about implementation may be found in today's > > ##taproot-activation log.[11] If it appears Speedy Trial may have > > traction, Russell O'Connor has offered to work on a patch against BIP8 > > implementing it. > > > > ## Acknowledgments > > > > The original idea for a short-duration attempt was discussed in the > > ##taproot-activation IRC channel last July and the revised idea saw > > additional evaluation there this week. Despite growing frustration, > > discussion has been overwhelmingly constructive, for which all the > > contributors should be commended. Although this should not in any way > > imply endorsement, I'm grateful for the review and comments on a draft > > of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher, > > Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell > > O'Connor, and IRC users maybehuman and proofofkeags > > > > ## Footnotes > > > > [1] > > https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see > >_what_happens.2C_BIP8.28false.2C_3m.29 > > > > [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period > > seemed to have near-universal support during the 2021-02-16 IRC > > meeting. See: > > https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102 > > > > [3] > > https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals&oldi > >d=68062 > > > > [4] https://github.com/bitcoin/bitcoin/pull/19953 > > > > [5] > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0175 > >47.html > > > > [6] https://github.com/bitcoin/bitcoin/pull/19573 > > > > [7] BIP9's times are based on the median of the past 11 blocks, which > > usually trails UTC by about 90 minutes but which can trail behind > > realtime significantly if miners are doing weird things. > > > > [8] https://en.bitcoin.it/wiki/July_2015_chain_forks > > > > [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32 > > > > [10] > > https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf > >9348f3a/src/test/versionbits_tests.cpp#L337-L339 > > > > [11] http://gnusha.org/taproot-activation/2021-03-05.log > > _______________________________________________ > > 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