[bitcoin-dev] Taproot activation proposal "Speedy Trial"

[bitcoin-dev] Taproot activation proposal "Speedy Trial"

[David A. Harding]

[-- Attachment #1: Type: text/plain, Size: 9290 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Jeremy]

[-- Attachment #1: Type: text/plain, Size: 10225 bytes --]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 13821 bytes --]

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Andrew Chow]

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&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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 12297 bytes --]

Hi Andrew,

This is a slight misunderstanding of the proposal.  Rather than an extended
lockin period (a term I've erroneously used in the past) it is really a
minimum activation height.

Thus using your figures it would instead be:

* start height = 681408 /* about May 1st */
* timeout height = 695520 /* about Aug 7th */
* min activation height = 709632 /* about Nov 13th */
* lockinontimeout = False
* signaling bit = 2
* threshold = 1815/2016 blocks (90%)

This guarantees 7 retargeting periods between start height and timeout
height.

Being able to make a guarantee about how many retargeting periods we get is
perhaps something worth pursuing given that the signaling period is so
short for this trial.

On Sat, Mar 6, 2021 at 1:04 AM Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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&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@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
>

[-- Attachment #2: Type: text/html, Size: 15995 bytes --]

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Luke Dashjr]

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

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Andrew Chow]

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@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

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Anthony Towns]

On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev wrote:
> ## Example timeline
> - 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)

> ### 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 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.

To get to specifics, here's a PR, based on #21334, that updates bip9
to support an extra parameter to delay the transition from LOCKED_IN
to ACTIVE until a particular timestamp is reached, and to reduce the
activation threshold to 90%:

  https://github.com/bitcoin/bitcoin/pull/21377

With that in mind, I think the example timeline above could translate
to taproot parameters of:

  nStartTime = 1618358400; // April 14, 2021
  nTimeout = 1626220800; // July 14 2021
  activation_time = 1633046400; // October 1 2021

That is, signalling begins with the first retarget period whose parent's
median time is at least April 14th; and concludes with the last retarget
period whose final block's median time is prior to July 14th; that's
91 days which should be about ~6.5 retarget periods, so should cover 6
full retarget periods, but could only cover 5.  Activation is delayed
until the first retarget period where the final block of the previous
retarget period has a timestamp of at least October 1st.

Note that the timeout there is prior to the expected timestamp of the
startheight block specified in the proposal for bip8 parameters:

  https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102

and earliest activation is after the expected release of 22.0 and hence
the maintenance end of 0.20.

Note also that the PR above specifies the delay as a deadline, not a
delta between lockin and activation; so earlier lockin does not produce
an earlier activation with the code referenced above.

Cheers,
aj

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Eric Voskuil]

The most sensible approach I’ve seen yet.

e

> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev wrote:
>> ## Example timeline
>> - 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)
> 
>> ### 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 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.
> 
> To get to specifics, here's a PR, based on #21334, that updates bip9
> to support an extra parameter to delay the transition from LOCKED_IN
> to ACTIVE until a particular timestamp is reached, and to reduce the
> activation threshold to 90%:
> 
>  https://github.com/bitcoin/bitcoin/pull/21377
> 
> With that in mind, I think the example timeline above could translate
> to taproot parameters of:
> 
>  nStartTime = 1618358400; // April 14, 2021
>  nTimeout = 1626220800; // July 14 2021
>  activation_time = 1633046400; // October 1 2021
> 
> That is, signalling begins with the first retarget period whose parent's
> median time is at least April 14th; and concludes with the last retarget
> period whose final block's median time is prior to July 14th; that's
> 91 days which should be about ~6.5 retarget periods, so should cover 6
> full retarget periods, but could only cover 5.  Activation is delayed
> until the first retarget period where the final block of the previous
> retarget period has a timestamp of at least October 1st.
> 
> Note that the timeout there is prior to the expected timestamp of the
> startheight block specified in the proposal for bip8 parameters:
> 
>  https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
> 
> and earliest activation is after the expected release of 22.0 and hence
> the maintenance end of 0.20.
> 
> Note also that the PR above specifies the delay as a deadline, not a
> delta between lockin and activation; so earlier lockin does not produce
> an earlier activation with the code referenced above.
> 
> Cheers,
> aj
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Matt Corallo]

I'm really unsure that three months is a short enough time window that there wouldn't be a material effort to split the 
network with divergent consensus rules. Instead, a three month window is certainly long enough to organize and make a 
lot of noise around such an effort, given BIP 148 was organized and reached its peak within a similar such window.

Worse, because the obvious alternative after a three month activation failure is a significant delay prior to 
activation, the vocal UASF minority may be encouraged to pursue such a route to avoid such a delay.

One alternative may be to reduce the signaling windows involved and start slightly later. Instead of the likelihood of 
failure growing on the horizon, simply have two signaling windows (maybe two weeks, maybe a moth each?). In order to 
ensure success remains likely, begin them somewhat later after software release to give pools and miners a chance to 
configure their mining software in advance.

Matt

On 3/5/21 22:43, 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&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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[David A. Harding]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

On Sat, Mar 06, 2021 at 01:11:01PM -0500, Matt Corallo wrote:
> I'm really unsure that three months is a short enough time window that there
> wouldn't be a material effort to split the network with divergent consensus
> rules. 

I oppose designing activation mechanisms with the goal of preventing
other people from effectively exercising self determination over what
consensus rules their nodes enforce.

Three months was chosen because it's long enough to give miners a
reasonable enough amount of time to activate taproot but it's also short
enough that it doesn't delay any of the existing proposals with roughly
one-year timelines.  As such, I think it has the potential to gain
acceptance from multiple current factions (even if it doesn't ever gain
their full approval), allowing us to move forward with rough social
consensus and to gain useful information from the attempt that can
inform future decisions.

-Dave

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Matt Corallo]

I don't think anyone is proposing anything to "prevent" other people from doing anything they wish. My understanding of 
the goal of this proposal, itself, was to keep the community together by proposing a solution that was palatable to all. 
My point was that I'm not sure that this proposal achieves its own goal, and that there may be solutions which are even 
more likely to keep the community of nodes together.

Matt

On 3/6/21 15:23, David A. Harding wrote:
> On Sat, Mar 06, 2021 at 01:11:01PM -0500, Matt Corallo wrote:
>> I'm really unsure that three months is a short enough time window that there
>> wouldn't be a material effort to split the network with divergent consensus
>> rules.
> 
> I oppose designing activation mechanisms with the goal of preventing
> other people from effectively exercising self determination over what
> consensus rules their nodes enforce.
> 
> Three months was chosen because it's long enough to give miners a
> reasonable enough amount of time to activate taproot but it's also short
> enough that it doesn't delay any of the existing proposals with roughly
> one-year timelines.  As such, I think it has the potential to gain
> acceptance from multiple current factions (even if it doesn't ever gain
> their full approval), allowing us to move forward with rough social
> consensus and to gain useful information from the attempt that can
> inform future decisions.
> 
> -Dave
> 

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Ariel Luaces]

On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm really unsure that three months is a short enough time window that there wouldn't be a material effort to split the
> network with divergent consensus rules. Instead, a three month window is certainly long enough to organize and make a
> lot of noise around such an effort, given BIP 148 was organized and reached its peak within a similar such window.
>
> Worse, because the obvious alternative after a three month activation failure is a significant delay prior to
> activation, the vocal UASF minority may be encouraged to pursue such a route to avoid such a delay.
>

I agree with your concern, a three month window motivates a small
group to constantly tell people to upgrade as soon as possible. Which
is mostly fine, but if this group gets near 51% mining support in the
three months it will embolden them to switch the messaging from
"upgrade the client" to "run this new client that has the LOT flag
switched to true" (UASF)
This marketing group will attempt a UASF regardless of the timelines
because there is no cost if they fail a UASF and there is great reward
if they succeed by activating in 3 months. They can run an alt-node,
scare everyone else of being reorged, pretend they have a majority,
and say their chain is the safe one. I say there is no cost because
the leaders of that movement are likely savvy enough to give up the
effort and move back to running core even after the chain split. The
ones who get hurt are the followers of the UASF movement that don't
fully understand the discussion and drink the kool aid.
A short time window doesn't preclude this group from attempting a UASF.

> One alternative may be to reduce the signaling windows involved and start slightly later. Instead of the likelihood of
> failure growing on the horizon, simply have two signaling windows (maybe two weeks, maybe a moth each?). In order to
> ensure success remains likely, begin them somewhat later after software release to give pools and miners a chance to
> configure their mining software in advance.
>
> Matt

The shorter the signaling windows the more unlikely they are to reach
a mining power supermajority.
With a short signaling window the supermajority threshold will
probably be configured to low levels (80% 70% 60%). Which makes the
activation period dangerous because it forces the other miners (20%
30% 40%) to upgrade really suddenly once the threshold is reached.
Unless the LOCKED_IN period is made really long (1 year) but then we
have to wait a really long time.
As long as the mining power running the soft fork is above 50% the
chain will stay together. Anything above that is just a safety margin
to prevent orphan blocks.

So why not encode this 50%+ dynamic into the activation logic.
Spread the deployment window out to a year, make the activation
threshold 95%, and at the end of the window the feature can activate
if there is above 51% signaling.
By definition, the activation will happen if either 95% is reached
early or if at the end of the deployment window mining support is
between 51% and 95%. With this setup the chain is guaranteed to stay
together and no need to rush miners and users.

Cheers
Ariel Lorenzo-Luaces

>
> On 3/5/21 22:43, 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&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@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

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Keagan McClelland]

[-- Attachment #1: Type: text/plain, Size: 15323 bytes --]

The assumption of malice on the part of those of us supporting a UASF is
tragic and frankly ridiculous. Many of us backed off of the effort the
second that this Speedy Trial solution was proposed in order to dislodge
the gridlock on the LOT value. I can't say for certain that 100% of those
working towards a UASF will abandon the effort but I can say for certain
that a good portion of the would be contributors to Bitcoin Activation have
already said that they would switch over to this Speedy Trial if it
actually materialized.

Given that the opposition towards the UASF to begin with was to not assume
malice out of miners I would expect that the same good will be extended to
those who were supporting a LOT=true client in good faith *given that Core
already said they wouldn't ship any activation code at all.*

Keagan

On Sat, Mar 6, 2021 at 1:49 PM Ariel Luaces via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Mar 6, 2021 at 10:11 AM Matt Corallo via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > I'm really unsure that three months is a short enough time window that
> there wouldn't be a material effort to split the
> > network with divergent consensus rules. Instead, a three month window is
> certainly long enough to organize and make a
> > lot of noise around such an effort, given BIP 148 was organized and
> reached its peak within a similar such window.
> >
> > Worse, because the obvious alternative after a three month activation
> failure is a significant delay prior to
> > activation, the vocal UASF minority may be encouraged to pursue such a
> route to avoid such a delay.
> >
>
> I agree with your concern, a three month window motivates a small
> group to constantly tell people to upgrade as soon as possible. Which
> is mostly fine, but if this group gets near 51% mining support in the
> three months it will embolden them to switch the messaging from
> "upgrade the client" to "run this new client that has the LOT flag
> switched to true" (UASF)
> This marketing group will attempt a UASF regardless of the timelines
> because there is no cost if they fail a UASF and there is great reward
> if they succeed by activating in 3 months. They can run an alt-node,
> scare everyone else of being reorged, pretend they have a majority,
> and say their chain is the safe one. I say there is no cost because
> the leaders of that movement are likely savvy enough to give up the
> effort and move back to running core even after the chain split. The
> ones who get hurt are the followers of the UASF movement that don't
> fully understand the discussion and drink the kool aid.
> A short time window doesn't preclude this group from attempting a UASF.
>
> > One alternative may be to reduce the signaling windows involved and
> start slightly later. Instead of the likelihood of
> > failure growing on the horizon, simply have two signaling windows (maybe
> two weeks, maybe a moth each?). In order to
> > ensure success remains likely, begin them somewhat later after software
> release to give pools and miners a chance to
> > configure their mining software in advance.
> >
> > Matt
>
> The shorter the signaling windows the more unlikely they are to reach
> a mining power supermajority.
> With a short signaling window the supermajority threshold will
> probably be configured to low levels (80% 70% 60%). Which makes the
> activation period dangerous because it forces the other miners (20%
> 30% 40%) to upgrade really suddenly once the threshold is reached.
> Unless the LOCKED_IN period is made really long (1 year) but then we
> have to wait a really long time.
> As long as the mining power running the soft fork is above 50% the
> chain will stay together. Anything above that is just a safety margin
> to prevent orphan blocks.
>
> So why not encode this 50%+ dynamic into the activation logic.
> Spread the deployment window out to a year, make the activation
> threshold 95%, and at the end of the window the feature can activate
> if there is above 51% signaling.
> By definition, the activation will happen if either 95% is reached
> early or if at the end of the deployment window mining support is
> between 51% and 95%. With this setup the chain is guaranteed to stay
> together and no need to rush miners and users.
>
> Cheers
> Ariel Lorenzo-Luaces
>
> >
> > On 3/5/21 22:43, 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&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@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
>

[-- Attachment #2: Type: text/html, Size: 19922 bytes --]

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Michael Folkson]

[-- Attachment #1: Type: text/plain, Size: 2982 bytes --]

Hi Matt

> I'm really unsure that three months is a short enough time window that
there wouldn't be a material effort to split the network with divergent
consensus rules. Instead, a three month window is certainly long enough to
organize and make a lot of noise around such an effort, given BIP 148 was
organized and reached its peak within a similar such window.

I'm not sure either. I can't control anyone other than myself. I think (and
Luke has also stated on IRC) that trying a UASF (LOT=true) during a "Speedy
Trial" deployment would be crazy. I would certainly recommend no one tries
that but I can't stop anyone. I'll repeat that soft forks have and always
will contain some limited chain split risk regardless of activation
mechanism. I think you are well intentioned but I'm not sure if you've
fully grasped that yet. Maybe you have and I'm missing something.

> Worse, because the obvious alternative after a three month activation
failure is a significant delay prior to activation, the vocal UASF minority
may be encouraged to pursue such a route to avoid such a delay.

Again I can only speak for myself but I wouldn't support a UASF until this
"fail fast" Speedy Trial has completed and failed. Luke agrees with that
and other people (eg proofofkeags) on the ##uasf IRC channel have also
supported this "Speedy Trial" proposal. If you want me (or anyone else for
that matter) to guarantee there won't be an attempted UASF during a Speedy
Trial deployment obviously nobody can do that. All I can say is that
personally I won't support one.

> One alternative may be to reduce the signaling windows involved and start
slightly later. Instead of the likelihood of failure growing on the
horizon, simply have two signaling windows (maybe two weeks, maybe a moth
each?). In order to ensure success remains likely, begin them somewhat
later after software release to give pools and miners a chance to configure
their mining software in advance.

The parameters for Speedy Trial are being hammered out on IRC as we speak.
I'd encourage you to engage with those discussions. I'd really like to
avoid a scenario where we have broad consensus on the details of Speedy
Trial and then you come out the woodwork weeks later with either an
alternative proposal or a criticism for how the details of Speedy Trial
were finalized.

I've read your email as you're concerned about a UASF during a Speedy Trial
deployment. Other than that I think (?) you support it and you are free to
join the discussion on IRC if you have particular views on parameters.
Personally I don't think those parameters should be chosen assuming there
will be a UASF during the deployment but you can argue that case on IRC if
you wish. All proposals you have personally put forward suffer from chain
split risk in the face of a competing incompatible activation mechanism.


-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

[-- Attachment #2: Type: text/html, Size: 3385 bytes --]

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Matt Corallo]

On 3/6/21 14:56, Michael Folkson wrote:
> Hi Matt
> 
>  > I'm really unsure that three months is a short enough time window that there wouldn't be a material effort to split 
> the network with divergent consensus rules. Instead, a three month window is certainly long enough to organize and make 
> a lot of noise around such an effort, given BIP 148 was organized and reached its peak within a similar such window.
> 
> I'm not sure either. I can't control anyone other than myself. I think (and Luke has also stated on IRC) that trying a 
> UASF (LOT=true) during a "Speedy Trial" deployment would be crazy. I would certainly recommend no one tries that but I 
> can't stop anyone. I'll repeat that soft forks have and always will contain some limited chain split risk regardless of 
> activation mechanism. I think you are well intentioned but I'm not sure if you've fully grasped that yet. Maybe you have 
> and I'm missing something.
> 
>  > Worse, because the obvious alternative after a three month activation failure is a significant delay prior to 
> activation, the vocal UASF minority may be encouraged to pursue such a route to avoid such a delay.
> 
> Again I can only speak for myself but I wouldn't support a UASF until this "fail fast" Speedy Trial has completed and 
> failed. Luke agrees with that and other people (eg proofofkeags) on the ##uasf IRC channel have also supported this 
> "Speedy Trial" proposal. If you want me (or anyone else for that matter) to guarantee there won't be an attempted UASF 
> during a Speedy Trial deployment obviously nobody can do that. All I can say is that personally I won't support one.

That's great to hear.

> The parameters for Speedy Trial are being hammered out on IRC as we speak. I'd encourage you to engage with those 
> discussions. I'd really like to avoid a scenario where we have broad consensus on the details of Speedy Trial and then 
> you come out the woodwork weeks later with either an alternative proposal or a criticism for how the details of Speedy 
> Trial were finalized.
 >
> I've read your email as you're concerned about a UASF during a Speedy Trial deployment. Other than that I think (?) you 
> support it and you are free to join the discussion on IRC if you have particular views on parameters. Personally I don't 
> think those parameters should be chosen assuming there will be a UASF during the deployment but you can argue that case 
> on IRC if you wish. All proposals you have personally put forward suffer from chain split risk in the face of a 
> competing incompatible activation mechanism.

The conversations around the activation of Taproot have far outgrown a single IRC channel, let alone a single live 
conversation. Nor is having a discussion with under a few days latency "coming out of the wordwork weeks later". 
Frankly, I find this more than a little insulting. Bitcoin's consensus has never been decided in such a manner and I see 
no reason to start now.

Re: [bitcoin-dev] Taproot activation proposal "Speedy Trial"

[Michael Folkson]

> 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.

Until Core pull request(s) are merged I don't think we can finalize
startheight (and hence the timeout) for Speedy Trial either.

Speedy Trial seems to have the most community consensus of any
activation proposal thus far and I'm confident it will at some point
in the near future it will be merged into Core.

Community feedback:
https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f

Therefore I think the onus is on any UASF release to fit around a
Speedy Trial deployment in Core. I haven't thought enough about what
my preference would be assuming activation fails with Speedy Trial re
a follow up deployment in Core and/or a UASF release. However, I would
be 100 percent opposed to any UASF release that conflicts or is not
compatible with a Speedy Trial deployment in Core.

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



-- 
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3