Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
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 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 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
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
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 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
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
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 " [...] 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/ signature.asc Description: PGP signature
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Update on "Speedy" Trial: The circus rolls on
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: michaelfolk...@gmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
