Andrew Chow [ARCHIVE] on Nostr: 📅 Original date posted:2021-03-15 📝 Original message:I don't think we should ...
📅 Original date posted:2021-03-15
📝 Original message:I don't think we should have a followup deployment start so close to to
timeout of ST. I think it would be better to schedule the followup
around ST, especially since the details around that are fuzzier and
dependent on the results of ST itself.
That being said, I'm not opposed to moving everything one period earlier
or shortening the activation or locked in periods, but I'm not sure if
that is the best course of action right now.
Andrew
On 3/14/21 10:51 PM, Luke Dashjr wrote:
> 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:I don't think we should have a followup deployment start so close to to
timeout of ST. I think it would be better to schedule the followup
around ST, especially since the details around that are fuzzier and
dependent on the results of ST itself.
That being said, I'm not opposed to moving everything one period earlier
or shortening the activation or locked in periods, but I'm not sure if
that is the best course of action right now.
Andrew
On 3/14/21 10:51 PM, Luke Dashjr wrote:
> 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev