{"type":"rich","version":"1.0","author_name":"npub1fgnnmg7f4wzup9hct8nv5pnd9l07wcjqdjku9ax432n4g69v4rgq7xak44","author_url":"https://nostr.ae/npub1fgnnmg7f4wzup9hct8nv5pnd9l07wcjqdjku9ax432n4g69v4rgq7xak44","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-03-15\n📝 Original message:I don't think we should have a followup deployment start so close to to\ntimeout of ST. I think it would be better to schedule the followup\naround ST, especially since the details around that are fuzzier and\ndependent on the results of ST itself.\n\nThat being said, I'm not opposed to moving everything one period earlier\nor shortening the activation or locked in periods, but I'm not sure if\nthat is the best course of action right now.\n\nAndrew\n\nOn 3/14/21 10:51 PM, Luke Dashjr wrote:\n\u003e The last period before timeoutheight here overlaps with the current BIP8(True)\n\u003e deployment plan. So if this period specifically were to reach 90% signalling,\n\u003e nodes would activate Taproot at height 697536, but ST-only nodes would still\n\u003e wait until 709632 instead.\n\u003e\n\u003e Probably the best solution is to just move this ST window 1 period earlier?\n\u003e\n\u003e Luke\n\u003e\n\u003e\n\u003e On Saturday 06 March 2021 06:04:22 Andrew Chow via bitcoin-dev wrote:\n\u003e\u003e I like this idea.\n\u003e\u003e\n\u003e\u003e In terms of actual parameters, I propose that we base this Speedy Trial\n\u003e\u003e off of BIP 8 with the following parameters:\n\u003e\u003e * start height = 681408\n\u003e\u003e * timeout height = 695520\n\u003e\u003e * lockinontimeout = False\n\u003e\u003e * signaling bit = 2\n\u003e\u003e * threshold = 1815/2016 blocks (90%)\n\u003e\u003e\n\u003e\u003e For the extended lockin period, I propose 14112 blocks, which is 7\n\u003e\u003e retarget periods. Thus the earliest activation height will be 697536 and\n\u003e\u003e the latest activation height will be 709632.\n\u003e\u003e\n\u003e\u003e This will give us an approximate start time of May 1st 2021 and an\n\u003e\u003e approximate timeout time of August 7th 2021, for a total activation\n\u003e\u003e period of just over 3 months. The extended lockin period is the same\n\u003e\u003e number of blocks as the activation period so that will also be just over\n\u003e\u003e 3 months, giving us the latest activation time of November 13th, 2021.\n\u003e\u003e If miners activated as soon as possible, the earliest activation time\n\u003e\u003e would be August 21st 2021.\n\u003e\u003e\n\u003e\u003e Additionally, this timeline assumes a mid-April release of Bitcoin Core\n\u003e\u003e 0.21.1 containing these parameters. They could be changed to move up if\n\u003e\u003e the expected release date were sooner.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Andrew Chow\n\u003e\u003e\n\u003e\u003e On 3/5/21 10:43 PM, David A. Harding via bitcoin-dev wrote:\n\u003e\u003e\u003e On the ##taproot-activation IRC channel, Russell O'Connor recently\n\u003e\u003e\u003e proposed a modification of the \"Let's see what happens\" activation\n\u003e\u003e\u003e proposal.[1] The idea received significant discussion and seemed\n\u003e\u003e\u003e acceptable to several people who could not previously agree on a\n\u003e\u003e\u003e proposal (although this doesn't necessarily make it their first\n\u003e\u003e\u003e choice).  The following is my attempt at a description.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 1. Start soon: shortly after the release of software containing this\n\u003e\u003e\u003e      proposed activation logic, nodes will begin counting blocks towards\n\u003e\u003e\u003e      the 90% threshold required to lock in taproot.[2]\n\u003e\u003e\u003e\n\u003e\u003e\u003e 2. Stop soon: if the lockin threshold isn't reached within approximately\n\u003e\u003e\u003e      three months, the activation attempt fails.  There is no mandatory\n\u003e\u003e\u003e      activation and everyone is encouraged to try again using different\n\u003e\u003e\u003e      activation parameters.\n\u003e\u003e\u003e\n\u003e\u003e\u003e 2. Delayed activation: in the happy occasion where the lockin threshold\n\u003e\u003e\u003e      is reached, taproot is guaranteed to eventually activate---but not\n\u003e\u003e\u003e      until approximately six months after signal tracking started.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Example timeline\n\u003e\u003e\u003e\n\u003e\u003e\u003e (All dates approximate; see the section below about BIP9 vs BIP8.)\n\u003e\u003e\u003e\n\u003e\u003e\u003e - T+0: release of one or more full nodes with activation code\n\u003e\u003e\u003e - T+14: signal tracking begins\n\u003e\u003e\u003e - T+28: earliest possible lock in\n\u003e\u003e\u003e - T+104: locked in by this date or need to try a different activation\n\u003e\u003e\u003e process - T+194: activation (if lockin occurred)\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Analysis\n\u003e\u003e\u003e\n\u003e\u003e\u003e The goal of Speedy Trial is to allow a taproot activation attempt to\n\u003e\u003e\u003e either quickly succeed or quickly fail---without compromising safety in\n\u003e\u003e\u003e either case.  Details below:\n\u003e\u003e\u003e\n\u003e\u003e\u003e ### Mitigating the problems of early success\n\u003e\u003e\u003e\n\u003e\u003e\u003e New rules added in a soft fork need to be enforced by a large part of\n\u003e\u003e\u003e the economy or there's a risk that a long chain of blocks breaking the\n\u003e\u003e\u003e rules will be accepted by some users and rejected by others, causing a\n\u003e\u003e\u003e chain split that can result in large direct losses to transaction\n\u003e\u003e\u003e receivers and potentially even larger indirect losses to holders due to\n\u003e\u003e\u003e reduced confidence in the safety of the Bitcoin system.\n\u003e\u003e\u003e\n\u003e\u003e\u003e One step developers have taken in the past to ensure widespread adoption\n\u003e\u003e\u003e of new consensus rules is programming in a delay between the time\n\u003e\u003e\u003e software with those rules is expected to be released and when the\n\u003e\u003e\u003e software starts tracking which blocks signal for activation.  For\n\u003e\u003e\u003e example:\n\u003e\u003e\u003e\n\u003e\u003e\u003e       Soft fork        | Release    | Start      | Delta\n\u003e\u003e\u003e       -----------------+------------+------------+----------\n\u003e\u003e\u003e       BIP68 (v0.12.1)  | 2016-04-15 | 2016-05-11 | 26 days\n\u003e\u003e\u003e       BIP141 (v0.13.1) | 2016-10-27 | 2016-11-18 | 24 days\n\u003e\u003e\u003e\n\u003e\u003e\u003e       Sources: BitcoinCore.org,\n\u003e\u003e\u003e https://gist.github.com/ajtowns/1c5e3b8bdead01124c04c45f01c817bc\n\u003e\u003e\u003e\n\u003e\u003e\u003e Speedy Trial replaces most of that upfront delay with a backend delay.\n\u003e\u003e\u003e No matter how fast taproot's activation threshold is reached by miners,\n\u003e\u003e\u003e there will be six months between the time signal tracking starts and when\n\u003e\u003e\u003e nodes will begin enforcing taproot's rules.  This gives the userbase even\n\u003e\u003e\u003e more time to upgrade than if we had used the most recently proposed start\n\u003e\u003e\u003e date for a BIP8 activation (~July 23rd).[2]\n\u003e\u003e\u003e\n\u003e\u003e\u003e ### Succeed, or fail fast\n\u003e\u003e\u003e\n\u003e\u003e\u003e The earlier version of this proposal was documented over 200 days ago[3]\n\u003e\u003e\u003e and taproot's underlying code was merged into Bitcoin Core over 140 days\n\u003e\u003e\u003e ago.[4]  If we had started Speedy Trial at the time taproot\n\u003e\u003e\u003e was merged (which is a bit unrealistic), we would've either be less than\n\u003e\u003e\u003e two months away from having taproot or we would have moved on to the\n\u003e\u003e\u003e next activation attempt over a month ago.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Instead, we've debated at length and don't appear to be any closer to\n\u003e\u003e\u003e what I think is a widely acceptable solution than when the mailing list\n\u003e\u003e\u003e began discussing post-segwit activation schemes over a year ago.[5]  I\n\u003e\u003e\u003e think Speedy Trial is a way to generate fast progress that will either\n\u003e\u003e\u003e end the debate (for now, if activation is successful) or give us some\n\u003e\u003e\u003e actual data upon which to base future taproot activation proposals.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Of course, for those who enjoy the debate, discussion can continue while\n\u003e\u003e\u003e waiting for the results of Speedy Trial.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ### Base activation protocol\n\u003e\u003e\u003e\n\u003e\u003e\u003e The idea can be implemented on top of either Bitcoin Core's existing\n\u003e\u003e\u003e BIP9 code or its proposed BIP8 patchset.[6]\n\u003e\u003e\u003e\n\u003e\u003e\u003e - BIP9 uses two time-based[7] parameters, starttime and timeout.  Using\n\u003e\u003e\u003e     these values plus a time-based parameter for the minimum activation\n\u003e\u003e\u003e     delay would give three months for miners to activate taproot, but some\n\u003e\u003e\u003e     of that time near the start or the end might not be usable due to\n\u003e\u003e\u003e     signals only being measured in full retarget periods.  However, the\n\u003e\u003e\u003e     six month time for users to upgrade their node would be not be\n\u003e\u003e\u003e     affected by either slow or fast block production.\n\u003e\u003e\u003e\n\u003e\u003e\u003e       BIP9 is already part of Bitcoin Core and I think the changes being\n\u003e\u003e\u003e       proposed would be relatively small, resulting in a small patch that\n\u003e\u003e\u003e       could be easy to review.\n\u003e\u003e\u003e\n\u003e\u003e\u003e - BIP8 uses two height-based parameters, startheight and timeoutheight.\n\u003e\u003e\u003e     Using height values would ensure miners had a certain number of\n\u003e\u003e\u003e     retarget periods (6) to lock in taproot and that there'd be a certain\n\u003e\u003e\u003e     number of blocks (about 24,000) until activation, although latest lock\n\u003e\u003e\u003e     in and expected activation could occur moderately earlier or later\n\u003e\u003e\u003e     than the estimated three and six months.\n\u003e\u003e\u003e\n\u003e\u003e\u003e       BIP8 would likely be used if Speedy Trial fails, so it could be\n\u003e\u003e\u003e       advantageous to base this proposal on BIP8 so that we gain\n\u003e\u003e\u003e       experience running that code in production.\n\u003e\u003e\u003e\n\u003e\u003e\u003e For additional discussion about using times versus heights, see today's\n\u003e\u003e\u003e log for ##taproot-activation.[11]\n\u003e\u003e\u003e\n\u003e\u003e\u003e ### Additional concerns\n\u003e\u003e\u003e\n\u003e\u003e\u003e - Encourages false signaling: false signaling is when miners signal\n\u003e\u003e\u003e     readiness to enforce rules that their nodes don't actually support.\n\u003e\u003e\u003e     This was partially responsible for a six-block reorg shortly after the\n\u003e\u003e\u003e     final BIP66 activation[8] and was found to still be a problem during\n\u003e\u003e\u003e     the BIP68 lockin period despite BIP9 being designed to avoid it.[9]\n\u003e\u003e\u003e\n\u003e\u003e\u003e     Because Speedy Trial only gives miners a maximum of three months to\n\u003e\u003e\u003e     signal support for taproot, it may encourage such false signaling.  If\n\u003e\u003e\u003e     taproot locks in as a result of their signaling but most of them fail\n\u003e\u003e\u003e     to upgrade by the activation date several months later, unprepared\n\u003e\u003e\u003e     miners could lose large amounts of money and users could see long\n\u003e\u003e\u003e     reorgs (with unupgraded nodes and SPV lite clients potentially losing\n\u003e\u003e\u003e     money).\n\u003e\u003e\u003e\n\u003e\u003e\u003e     Compared to other activation proposals, I think the only difference is\n\u003e\u003e\u003e     Speedy Trial's short timeline.  False signaling is possible with any\n\u003e\u003e\u003e     other proposal and the same problems can occur if miners fail to\n\u003e\u003e\u003e     upgrade for any mandatory activation.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ### Additional advantages\n\u003e\u003e\u003e\n\u003e\u003e\u003e - No mandatory signaling: at no time are miners required to signal by\n\u003e\u003e\u003e     Speedy Trial.  This includes no mandatory signaling during the\n\u003e\u003e\u003e     locked_in period(s), although such signaling will be encouraged (as it\n\u003e\u003e\u003e     was with BIP9[10]).\n\u003e\u003e\u003e\n\u003e\u003e\u003e - Party time: to a lesser degree, a benefit mentioned for flag day\n\u003e\u003e\u003e     activation may also apply here: we could get up to six months\n\u003e\u003e\u003e     advanced notice of taproot activation, allowing users, developers, and\n\u003e\u003e\u003e     organizations to prepare software, announcements, and celebrations for\n\u003e\u003e\u003e     that event.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Implementation details and next steps\n\u003e\u003e\u003e\n\u003e\u003e\u003e Initial discussion about implementation may be found in today's\n\u003e\u003e\u003e ##taproot-activation log.[11] If it appears Speedy Trial may have\n\u003e\u003e\u003e traction, Russell O'Connor has offered to work on a patch against BIP8\n\u003e\u003e\u003e implementing it.\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Acknowledgments\n\u003e\u003e\u003e\n\u003e\u003e\u003e The original idea for a short-duration attempt was discussed in the\n\u003e\u003e\u003e ##taproot-activation IRC channel last July and the revised idea saw\n\u003e\u003e\u003e additional evaluation there this week.  Despite growing frustration,\n\u003e\u003e\u003e discussion has been overwhelmingly constructive, for which all the\n\u003e\u003e\u003e contributors should be commended.  Although this should not in any way\n\u003e\u003e\u003e imply endorsement, I'm grateful for the review and comments on a draft\n\u003e\u003e\u003e of this email by Adam Gibson, Andrew Chow, Anthony Towns, Chris Belcher,\n\u003e\u003e\u003e Jeremy Rubin, Jonas Nick, Luke Dashjr, Michael Folkson, Russell\n\u003e\u003e\u003e O'Connor, and IRC users maybehuman and proofofkeags\n\u003e\u003e\u003e\n\u003e\u003e\u003e ## Footnotes\n\u003e\u003e\u003e\n\u003e\u003e\u003e [1]\n\u003e\u003e\u003e https://en.bitcoin.it/wiki/Taproot_activation_proposals#Let.E2.80.99s_see\n\u003e\u003e\u003e _what_happens.2C_BIP8.28false.2C_3m.29\n\u003e\u003e\u003e\n\u003e\u003e\u003e [2] A threshold of 1,815/2,016 blocks (90%) in a single retarget period\n\u003e\u003e\u003e       seemed to have near-universal support during the 2021-02-16 IRC\n\u003e\u003e\u003e       meeting.  See:\n\u003e\u003e\u003e https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102\n\u003e\u003e\u003e\n\u003e\u003e\u003e [3]\n\u003e\u003e\u003e https://en.bitcoin.it/w/index.php?title=Taproot_activation_proposals\u0026oldi\n\u003e\u003e\u003e d=68062\n\u003e\u003e\u003e\n\u003e\u003e\u003e [4] https://github.com/bitcoin/bitcoin/pull/19953\n\u003e\u003e\u003e\n\u003e\u003e\u003e [5]\n\u003e\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/0175\n\u003e\u003e\u003e 47.html\n\u003e\u003e\u003e\n\u003e\u003e\u003e [6] https://github.com/bitcoin/bitcoin/pull/19573\n\u003e\u003e\u003e\n\u003e\u003e\u003e [7] BIP9's times are based on the median of the past 11 blocks, which\n\u003e\u003e\u003e       usually trails UTC by about 90 minutes but which can trail behind\n\u003e\u003e\u003e       realtime significantly if miners are doing weird things.\n\u003e\u003e\u003e\n\u003e\u003e\u003e [8] https://en.bitcoin.it/wiki/July_2015_chain_forks\n\u003e\u003e\u003e\n\u003e\u003e\u003e [9] https://buildingbitcoin.org/bitcoin-core-dev/log-2016-06-21.html#l-32\n\u003e\u003e\u003e\n\u003e\u003e\u003e [10]\n\u003e\u003e\u003e https://github.com/bitcoin/bitcoin/blob/ed25cb58f605ba583c735f330482df0bf\n\u003e\u003e\u003e 9348f3a/src/test/versionbits_tests.cpp#L337-L339\n\u003e\u003e\u003e\n\u003e\u003e\u003e [11] http://gnusha.org/taproot-activation/2021-03-05.log\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}