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 <bitcoin-dev@lists.linuxfoundation.org> 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?" Strongly > benefits from a guaranteed number of signaling periods that height based > activation offers. Especially for the short activation period of Speedy > Trial. > > The other relevant value of giving enough time for users to upgrade is not > very sensitive. It's not like 180 days is magic number that going over is > 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 > signaling start and end dates to line up in the middle of expected > retargeting periods that we would otherwise chose with height based > activation. Why we would rather use MTP to fake a height based activation, I > will never understand. But if this is what it takes to activate taproot, that > is fine by me. > > The differences between height and MTP activation are too small to matter > that much for what is ultimately transient code. As long as MTP activation > can pass code review it is okay with me. > > > On Mon., Apr. 5, 2021, 06:35 Anthony Towns via bitcoin-dev, > <bitcoin-dev@lists.linuxfoundation.org> 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 delay >> 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 signal, >> 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 at >> 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-621934640 >> >> 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
