[bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[Michael Folkson]

I will continue to update the list on the latest developments as I see
them. That's all I can do.

So the latest circus act is apparently a technical decision made by a
coin toss. The rationale being that this discussion on using block
height vs a mix of block height and MTP was bikeshedding all along.

Here's a short abridged timeline on the views on block height vs MTP
of the organizer (Jeremy Rubin) of that coin toss:

March 8th: "I have a preference for fully height based design,
correct." https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-802396191

March 24th: "There are two NACKs, one (luke-jr) against MTP, one
(jeremyrubin) against height.”
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018715.html

April 6th: "The following folks in the meeting agreed to abide by the
flip.... jeremyrubin"
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018742.html

April 7th: "So @achow101 is correct that it is not the coin flip which
made the decision."
https://github.com/bitcoin/bitcoin/pull/21393#issuecomment-815388126

Please note on March 24th the only person NACKing block height in that
meeting was Jeremy Rubin. He has gone from preferring block height, to
NACKing block height, to thinking this discussion all along was
bikeshedding and worthy of a coin flip to admitting the coin flip was
theater.

All of this makes me extremely uncomfortable and I dread to think what
individuals and businesses all over the world who have plans to
utilize and build on Taproot are making of all of this. As an
individual I would like to distance myself from this circus. I will
try to keep the mailing list informed though of further developments
re Speedy Trial in Core or progress on an alternative client.

There are two StackExchange answers here on block height vs MTP, one
by David Harding and one by myself for those that are interested in
the technical considerations.
https://bitcoin.stackexchange.com/questions/103854/should-block-height-or-mtp-or-a-mixture-of-both-be-used-in-a-soft-fork-activatio

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

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[Andrew Poelstra]

On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
> 
> All of this makes me extremely uncomfortable and I dread to think what
> individuals and businesses all over the world who have plans to
> utilize and build on Taproot are making of all of this. As an
> individual I would like to distance myself from this circus. I will
> try to keep the mailing list informed though of further developments
> re Speedy Trial in Core or progress on an alternative client.
>

Thank you for your updates.


For what it's worth, as somebody who wants to use Taproot I don't care *at
all* about activation parameters, and I especially don't care about block
height vs MTP.

If a coin toss is what it takes for people to move past this that's fine
by me.


 
-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[Matt Corallo]

Probably worth noting, but while the coin toss was acceptable to many people as "who cares, just move on", the two 
authors of actual code for the two proposals here also came to an agreement on a way forward, so its not like it was a 
"coin toss to overrule everyone on 'the other side'".

On 4/8/21 10:30, Andrew Poelstra via bitcoin-dev wrote:
> On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
>>
>> All of this makes me extremely uncomfortable and I dread to think what
>> individuals and businesses all over the world who have plans to
>> utilize and build on Taproot are making of all of this. As an
>> individual I would like to distance myself from this circus. I will
>> try to keep the mailing list informed though of further developments
>> re Speedy Trial in Core or progress on an alternative client.
>>
> 
> Thank you for your updates.
> 
> 
> For what it's worth, as somebody who wants to use Taproot I don't care *at
> all* about activation parameters, and I especially don't care about block
> height vs MTP.
> 
> If a coin toss is what it takes for people to move past this that's fine
> by me.
> 
> 
>   
> 

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[David A. Harding]

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

On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
> So the latest circus act is apparently a technical decision made by a
> coin toss [organized by] Jeremy Rubin

Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2],
and is the same method I've been using in Bitcoin-related discussions
for over seven years[3] to help people transition from ancillary arguments
back to working on the things they really think are important.

I proposed the coin toss because I understood that both the MTP and the
height approaches required tradeoffs that were, to a certain degree,
unresolvable to the best of our current knowledge.  MTP is harder to
analyze for unexpected edge cases; heights would create extra work for
seasoned developers working on post-taproot soft forks.  MTP would
require developers of currently-planned UASF software either do extra
work or wait to release their software; heights don't guarantee a
minimum amount of time for a large number of economic full nodes to
upgrade.

Different people gave different weights to the different tradeoffs.  In
cases like this where there's no known way to eliminate the tradeoffs
and no way to objectively rank them, I think it's better to begin
working on something concrete than it is to try to persuade everyone to
adopt the same subjective ranking of the tradeoffs---or, as the IETF
published in RFC7282:

    "There are times where the result of [an informal open-ended
    conversation] is a pretty even split.  In practical terms, that
    means it doesn't matter where the chair starts the discussion.  And
    in fact, we've had working groups where a coin flip decided which
    proposal to start with.  That doesn't mean that the coin flip
    determined the outcome; if a fatal technical flaw was found in the
    solution that won the coin flip, it is still incumbent upon the
    group to address the issue raised or abandon that solution and find
    another.  Rough consensus on the technical points, in the end, is
    always required.  Any way to find a place to start, be it the hum or
    the coin flip, is only getting to the beginning of the discussion,
    not the end."

As Jeremy wrote, in this occassion, we didn't actually need the coin
toss.  The authors of the two PRs we were considering found a compromise
solution that seems to be good enough for both of them and which so far
seems to be good enough for the handful of people who agreed to the coin
toss (plus, it seems, several others who didn't agree to the toss).

In short, I think the coin toss was a good attempt.  Although we didn't
use its results this time, I think it's something we should keep in our
toolkit for the future when a group of people want to coordinate their
work on getting *a* solution released, even in cases where they don't
necessarily start out in agreement about which solution is best.

> I dread to think what individuals and businesses all over the world
> who have plans to utilize and build on Taproot are making of all of
> this. 

Geeks arguing over minutia is a well established stereotype.  That we've
conformed to that stereotype in this case is not great---but I don't
think it does us any significant reputational harm.  I hope those
individuals and businesses awaiting taproot are discerning enough to
realize that the method we use to activate taproot has nothing to do
with taproot itself.  I hope they realize that it remains the case that
there is nearly universal support for taproot from every entity that has
so far commented on it.

Hopefully we've made progress on Speedy Trial this week, that progress
will continue and we'll be able to release activation-ready software
soon, miners will be willing to signal for taproot, and we'll soon be
able to end this chapter in Bitcoin's storied history of soft fork
activations.[4]  (But I look forward to continued discussion about
better activation mechanisms for the future---if taproot locks in
quickly, I'd love to see human consensus form around a follow-up
deployment even before taproot reaches activation.)

Respectfully,

-Dave

[1] http://gnusha.org/taproot-activation/2021-04-04.log "<harding> [...]
If that's not our goal and we just want to give miners a chance to
activate taproot as soon as possible (which was certainly my original
objective in supporting ST), I'm personally happy with either MTP or
heights, and I'd be willing to join others in putting my effort behind
just one of them based on fair random chance."

[2] http://gnusha.org/taproot-activation/2021-04-04.log "18:09 <
harding> e.g.:   bitcoin-cli getblockhash 123456 | cut -b64 | grep -q
'[02468ace]' && echo MTP || echo height"

[3] E.g.,
https://github.com/bitcoin-dot-org/Bitcoin.org/pull/589#discussion_r18314009
and https://github.com/bitcoin-dot-org/Bitcoin.org/pull/566#issuecomment-56281595

[4] https://bitcoinops.org/en/topics/soft-fork-activation/

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

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[Michael Folkson]

I have no problem with coin tosses to decide for example shed colors
(an illustrative example discussed by copumpkin, roasbeef on IRC). In
this kind of example everyone should recognize it doesn't matter and
Approach ACK two competing PRs. No one should be NACKing or Approach
NACKing a PR based on shed color. If the maintainers don't care about
the shed color either then they are free to use a coin toss to decide
which PR to merge. In this example there shouldn't be any NACKs,
Approach NACKs or technical opposition from regular Core reviewers.
NACKs are not meant to be used for shed colors.

However, in this example the organizer of the coin toss had previously
NACKed one of the options (block height, though his position seems to
change by the day) and others have NACKed MTP. I think you have
consistently said it doesn't matter too much although you did
previously express a preference for block height.

I don't want to belabor the point but can we avoid even suggesting
using coin tosses on consensus code decisions in future please? It
makes a mockery of those who spent time understanding the technical
considerations and have spent months or years working on soft fork
activations. Even in the shed color example, leave it to the
maintainers to decide whether a coin toss is appropriate rather than
creating a circus around a coin toss in a public meeting where the PR
authors weren't present and no Core maintainers were present.

I understand the frustration and I understand the desire to break
deadlocks. But if the coin toss organizer hadn't previously NACKed one
of the options (block height) we may have avoided getting into this
deadlock in the first place.

Your recent review notes of PR #21377 look great and are proving very
helpful to me as I look at the PR.
https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40

Thanks
Michael

On Thu, Apr 8, 2021 at 10:57 PM David A. Harding <dave@dtrt.org> wrote:
>
> On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
> > So the latest circus act is apparently a technical decision made by a
> > coin toss [organized by] Jeremy Rubin
>
> Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2],
> and is the same method I've been using in Bitcoin-related discussions
> for over seven years[3] to help people transition from ancillary arguments
> back to working on the things they really think are important.
>
> I proposed the coin toss because I understood that both the MTP and the
> height approaches required tradeoffs that were, to a certain degree,
> unresolvable to the best of our current knowledge.  MTP is harder to
> analyze for unexpected edge cases; heights would create extra work for
> seasoned developers working on post-taproot soft forks.  MTP would
> require developers of currently-planned UASF software either do extra
> work or wait to release their software; heights don't guarantee a
> minimum amount of time for a large number of economic full nodes to
> upgrade.
>
> Different people gave different weights to the different tradeoffs.  In
> cases like this where there's no known way to eliminate the tradeoffs
> and no way to objectively rank them, I think it's better to begin
> working on something concrete than it is to try to persuade everyone to
> adopt the same subjective ranking of the tradeoffs---or, as the IETF
> published in RFC7282:
>
>     "There are times where the result of [an informal open-ended
>     conversation] is a pretty even split.  In practical terms, that
>     means it doesn't matter where the chair starts the discussion.  And
>     in fact, we've had working groups where a coin flip decided which
>     proposal to start with.  That doesn't mean that the coin flip
>     determined the outcome; if a fatal technical flaw was found in the
>     solution that won the coin flip, it is still incumbent upon the
>     group to address the issue raised or abandon that solution and find
>     another.  Rough consensus on the technical points, in the end, is
>     always required.  Any way to find a place to start, be it the hum or
>     the coin flip, is only getting to the beginning of the discussion,
>     not the end."
>
> As Jeremy wrote, in this occassion, we didn't actually need the coin
> toss.  The authors of the two PRs we were considering found a compromise
> solution that seems to be good enough for both of them and which so far
> seems to be good enough for the handful of people who agreed to the coin
> toss (plus, it seems, several others who didn't agree to the toss).
>
> In short, I think the coin toss was a good attempt.  Although we didn't
> use its results this time, I think it's something we should keep in our
> toolkit for the future when a group of people want to coordinate their
> work on getting *a* solution released, even in cases where they don't
> necessarily start out in agreement about which solution is best.
>
> > I dread to think what individuals and businesses all over the world
> > who have plans to utilize and build on Taproot are making of all of
> > this.
>
> Geeks arguing over minutia is a well established stereotype.  That we've
> conformed to that stereotype in this case is not great---but I don't
> think it does us any significant reputational harm.  I hope those
> individuals and businesses awaiting taproot are discerning enough to
> realize that the method we use to activate taproot has nothing to do
> with taproot itself.  I hope they realize that it remains the case that
> there is nearly universal support for taproot from every entity that has
> so far commented on it.
>
> Hopefully we've made progress on Speedy Trial this week, that progress
> will continue and we'll be able to release activation-ready software
> soon, miners will be willing to signal for taproot, and we'll soon be
> able to end this chapter in Bitcoin's storied history of soft fork
> activations.[4]  (But I look forward to continued discussion about
> better activation mechanisms for the future---if taproot locks in
> quickly, I'd love to see human consensus form around a follow-up
> deployment even before taproot reaches activation.)
>
> Respectfully,
>
> -Dave
>
> [1] http://gnusha.org/taproot-activation/2021-04-04.log "<harding> [...]
> If that's not our goal and we just want to give miners a chance to
> activate taproot as soon as possible (which was certainly my original
> objective in supporting ST), I'm personally happy with either MTP or
> heights, and I'd be willing to join others in putting my effort behind
> just one of them based on fair random chance."
>
> [2] http://gnusha.org/taproot-activation/2021-04-04.log "18:09 <
> harding> e.g.:   bitcoin-cli getblockhash 123456 | cut -b64 | grep -q
> '[02468ace]' && echo MTP || echo height"
>
> [3] E.g.,
> https://github.com/bitcoin-dot-org/Bitcoin.org/pull/589#discussion_r18314009
> and https://github.com/bitcoin-dot-org/Bitcoin.org/pull/566#issuecomment-56281595
>
> [4] https://bitcoinops.org/en/topics/soft-fork-activation/



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

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

[Michael Folkson]

In my previous email in response to David Harding I said:
"I think you have consistently said it doesn't matter too much
although you did previously express a preference for block height."

This was based on:
"My preference would be for whatever solution is most preferred by
reviewers." March 7th
https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-792220340

With a greater number of PR comments preferring block height at this
point I concluded that this equated to a preference for block height.
I'm happy to correct my previous statement having spoken to David.
This did not equate to a preference and David was entirely neutral.

For the sake of the mailing list (even though David didn't do so)
expressing preferences on a PR is absolutely fine. It is fine to say
"This is my preference" without NACKing a PR or NACKing a technical
decision. I (and many others) have done this. Maintainers can look
through the PR, read the rationales for the preferences and still
consider merging the PR. However, well reasoned NACKs (e.g. Concept,
Approach NACKs) make it difficult for maintainers to merge a PR
especially if they are from long term contributors. If you oscillate
from a preference one way to a full on NACK the other way to "Let's
coin flip it" with minimal rationale you are making maintainers' jobs
even more difficult. You are also wasting the time of reviewers who
don't know which PR to review and which PR stands a better chance of
being merged. You are also (unintentionally) increasing the risk of
bugs not being caught because the PR that eventually gets merged
hasn't received the review it could have.

I have been criticized on IRC for the tone of my emails. To be clear I
take Taproot activation seriously, I take the Core review process
seriously and I take keeping the community informed of the likely
timetable seriously. I'm not impressed by people wasting my time and
I'm doubly not impressed by people wasting other Core reviewers' time
and maintainers' time. If that informs my tone so be it. This is not
directed towards David who has worked hard to make progress with
Taproot activation, hasn't wasted anyone's time and I have a huge
amount of respect for.

In terms of the latest state of play with Core, there is an open Core
PR for Speedy Trial (#21377) that appears to be our best chance of
getting activation code merged into Core. The more testing and code
review this Core PR receives the better. If it continues to make
progress the discussion will then need to move onto a timetable.

On Fri, Apr 9, 2021 at 12:19 PM Michael Folkson
<michaelfolkson@gmail.com> wrote:
>
> I have no problem with coin tosses to decide for example shed colors
> (an illustrative example discussed by copumpkin, roasbeef on IRC). In
> this kind of example everyone should recognize it doesn't matter and
> Approach ACK two competing PRs. No one should be NACKing or Approach
> NACKing a PR based on shed color. If the maintainers don't care about
> the shed color either then they are free to use a coin toss to decide
> which PR to merge. In this example there shouldn't be any NACKs,
> Approach NACKs or technical opposition from regular Core reviewers.
> NACKs are not meant to be used for shed colors.
>
> However, in this example the organizer of the coin toss had previously
> NACKed one of the options (block height, though his position seems to
> change by the day) and others have NACKed MTP. I think you have
> consistently said it doesn't matter too much although you did
> previously express a preference for block height.
>
> I don't want to belabor the point but can we avoid even suggesting
> using coin tosses on consensus code decisions in future please? It
> makes a mockery of those who spent time understanding the technical
> considerations and have spent months or years working on soft fork
> activations. Even in the shed color example, leave it to the
> maintainers to decide whether a coin toss is appropriate rather than
> creating a circus around a coin toss in a public meeting where the PR
> authors weren't present and no Core maintainers were present.
>
> I understand the frustration and I understand the desire to break
> deadlocks. But if the coin toss organizer hadn't previously NACKed one
> of the options (block height) we may have avoided getting into this
> deadlock in the first place.
>
> Your recent review notes of PR #21377 look great and are proving very
> helpful to me as I look at the PR.
> https://gist.github.com/harding/e622323eaf80d620826a7cb74ab3fb40
>
> Thanks
> Michael
>
> On Thu, Apr 8, 2021 at 10:57 PM David A. Harding <dave@dtrt.org> wrote:
> >
> > On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
> > > So the latest circus act is apparently a technical decision made by a
> > > coin toss [organized by] Jeremy Rubin
> >
> > Actually, the coin toss was my idea[1], used a bash oneliner I wrote[2],
> > and is the same method I've been using in Bitcoin-related discussions
> > for over seven years[3] to help people transition from ancillary arguments
> > back to working on the things they really think are important.
> >
> > I proposed the coin toss because I understood that both the MTP and the
> > height approaches required tradeoffs that were, to a certain degree,
> > unresolvable to the best of our current knowledge.  MTP is harder to
> > analyze for unexpected edge cases; heights would create extra work for
> > seasoned developers working on post-taproot soft forks.  MTP would
> > require developers of currently-planned UASF software either do extra
> > work or wait to release their software; heights don't guarantee a
> > minimum amount of time for a large number of economic full nodes to
> > upgrade.
> >
> > Different people gave different weights to the different tradeoffs.  In
> > cases like this where there's no known way to eliminate the tradeoffs
> > and no way to objectively rank them, I think it's better to begin
> > working on something concrete than it is to try to persuade everyone to
> > adopt the same subjective ranking of the tradeoffs---or, as the IETF
> > published in RFC7282:
> >
> >     "There are times where the result of [an informal open-ended
> >     conversation] is a pretty even split.  In practical terms, that
> >     means it doesn't matter where the chair starts the discussion.  And
> >     in fact, we've had working groups where a coin flip decided which
> >     proposal to start with.  That doesn't mean that the coin flip
> >     determined the outcome; if a fatal technical flaw was found in the
> >     solution that won the coin flip, it is still incumbent upon the
> >     group to address the issue raised or abandon that solution and find
> >     another.  Rough consensus on the technical points, in the end, is
> >     always required.  Any way to find a place to start, be it the hum or
> >     the coin flip, is only getting to the beginning of the discussion,
> >     not the end."
> >
> > As Jeremy wrote, in this occassion, we didn't actually need the coin
> > toss.  The authors of the two PRs we were considering found a compromise
> > solution that seems to be good enough for both of them and which so far
> > seems to be good enough for the handful of people who agreed to the coin
> > toss (plus, it seems, several others who didn't agree to the toss).
> >
> > In short, I think the coin toss was a good attempt.  Although we didn't
> > use its results this time, I think it's something we should keep in our
> > toolkit for the future when a group of people want to coordinate their
> > work on getting *a* solution released, even in cases where they don't
> > necessarily start out in agreement about which solution is best.
> >
> > > I dread to think what individuals and businesses all over the world
> > > who have plans to utilize and build on Taproot are making of all of
> > > this.
> >
> > Geeks arguing over minutia is a well established stereotype.  That we've
> > conformed to that stereotype in this case is not great---but I don't
> > think it does us any significant reputational harm.  I hope those
> > individuals and businesses awaiting taproot are discerning enough to
> > realize that the method we use to activate taproot has nothing to do
> > with taproot itself.  I hope they realize that it remains the case that
> > there is nearly universal support for taproot from every entity that has
> > so far commented on it.
> >
> > Hopefully we've made progress on Speedy Trial this week, that progress
> > will continue and we'll be able to release activation-ready software
> > soon, miners will be willing to signal for taproot, and we'll soon be
> > able to end this chapter in Bitcoin's storied history of soft fork
> > activations.[4]  (But I look forward to continued discussion about
> > better activation mechanisms for the future---if taproot locks in
> > quickly, I'd love to see human consensus form around a follow-up
> > deployment even before taproot reaches activation.)
> >
> > Respectfully,
> >
> > -Dave
> >
> > [1] http://gnusha.org/taproot-activation/2021-04-04.log "<harding> [...]
> > If that's not our goal and we just want to give miners a chance to
> > activate taproot as soon as possible (which was certainly my original
> > objective in supporting ST), I'm personally happy with either MTP or
> > heights, and I'd be willing to join others in putting my effort behind
> > just one of them based on fair random chance."
> >
> > [2] http://gnusha.org/taproot-activation/2021-04-04.log "18:09 <
> > harding> e.g.:   bitcoin-cli getblockhash 123456 | cut -b64 | grep -q
> > '[02468ace]' && echo MTP || echo height"
> >
> > [3] E.g.,
> > https://github.com/bitcoin-dot-org/Bitcoin.org/pull/589#discussion_r18314009
> > and https://github.com/bitcoin-dot-org/Bitcoin.org/pull/566#issuecomment-56281595
> >
> > [4] https://bitcoinops.org/en/topics/soft-fork-activation/
>
>
>
> --
> Michael Folkson
> Email: michaelfolkson@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3



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