rich1.0npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtahttps://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtanjumphttps://nostr.ae📅 Original date posted:2021-03-06 📝 Original message:Thank you for resurfacing and collating this concept. At this time I don't see major issues with this course of action and think it represents not only a reasonable compromise between all different perspectives, but also gives us an opportunity to learn more about less 'slow' yet safe consensus upgrades. In particular, I am very happy to see the earliest activation concept included. Best, Jeremy -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Fri, Mar 5, 2021 at 7:44 PM David A. Harding via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> 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&oldid=68062 > > [4] https://github.com/bitcoin/bitcoin/pull/19953 > > [5] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.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/ed25cb58f605ba583c735f330482df0bf9348f3a/src/test/versionbits_tests.cpp#L337-L339 > > [11] http://gnusha.org/taproot-activation/2021-03-05.log > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210305/13bc9b4e/attachment-0001.html>