On Consensus and Humming in the IETF
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.
[Tuesday, March 23, 2021] [12:23:07 PM PDT] <BlueMatt> but, frankly, flip a coin for all I care - as jeremyrubin pointed out multiple times, it doesn't matter in practice of how it would work in the real world.
[Sunday, April 4, 2021] [3:25:29 PM PDT] <harding> If there's sentiment that the benefit of proceeding with one method now outweighs the benefit of trying to find the best possible method, we could all commit to letting a fair coin toss decide (e.g. if the least significant bit of block x is 0, we use MTP; if it's 1, we use height).
[Tuesday, April 6, 2021] [12:28:38 PM PDT] <rgrant> I'd like to point back to April 4th, where a coin toss was proposed. I would accept a coin toss and feel we're very close.
[Tuesday, April 6, 2021] [12:32:46 PM PDT] <OP_NOP> jeremyrubin: I think most people just want to move forward with something, hence the growing consensus around a coin flip
[Tuesday, April 6, 2021] [1:09:22 PM PDT] <rgrant> This topic seems to be winding down. I'm hearing: that signet configuration isn't a dealbreaker but there is technical debt incurred if we ignore it; MTP-based activation (read: celebration parties) can be known weeks in advance if parameters are chosen well; and that code reviews matter. Coinflip seems to be winning.
[Tuesday, April 6, 2021] [1:22:10 PM PDT] <jeremyrubin> And coinflip will be (either AJ and Achow agree on a path || coinflip)
[Tuesday, April 6, 2021] [1:27:57 PM PDT] <jeremyrubin> I think a rough plan is that everyone who signed up to coinflip should review carefully, and then, barring any concerns, ACK the relevent PR.
[Thursday, April 8, 2021] [7:44:35 AM PDT] <AaronvanW> if we're doing coin flips to decide on activation parameters, can't we just do a coin flip between LOT=true and LOT=false...
[Thursday, April 8, 2021] [7:44:50 AM PDT] <AaronvanW> (I remember that adam3us literally suggested that a couple months ago.)
[Thursday, April 8, 2021] [7:45:10 AM PDT] <copumpkin> I think you'll find fewer people who consider those to be equivalent enough that they don't care about the outcome of the coinflip :)
[Tuesday, April 6, 2021] [12:00:08 PM PDT] <jeremyrubin> #startmeeting
[Tuesday, April 6, 2021] [12:01:23 PM PDT] <aj> hi
[Tuesday, April 6, 2021] [12:02:52 PM PDT] <achow101> hello
It is important to correct this because it furthers an myth that bitcoin developers (especially maintainers) are somehow uniquely in control, a myth which is harmful to both the maintainers and the project itself.
Please review: https://bitcoincore.org/en/about/
Team
The Bitcoin Core project has a large open source developer community with many casual contributors to the codebase. There are many more who contribute research, peer review, testing, documentation, and translation.
Maintainers
Project maintainers have commit access and are responsible for merging patches from contributors. They perform a janitorial role merging patches that the team agrees should be merged. They also act as a final check to ensure that patches are safe and in line with the project goals. The maintainers’ role is by agreement of project contributors.
Contributors
Everyone is free to propose code changes and to test, review and comment on open Pull Requests. Anyone who contributes code, review, test, translation or documentation to the Bitcoin Core project is considered a contributor. The release notes for each Bitcoin Core software release contain a credits section to recognize all those who have contributed to the project over the previous release cycle. A list of code contributors can be found on Github.
Maintainers do not have any special privilege over contributors and serve more or less at the pleasure of the project's contributors. Complaining that none of 4 current maintainers were present is irrelevant for a meeting that had a diverse range of contributors and team members, presence of a maintainer would only provide further legitimacy to the extent that another regular contributor was present. Maintainers will do their duty to review patches before merging the patches.
You're misrepresenting here not only my NACK, but also your goal in creating uncertainty around the outcome of this week's meeting and the rough consensus around AJ's PR #21377. Your goal (as stated below) seems to be ensuring that ST fails to reach rough consensus so that you can drive a UASF.
[Tuesday, March 23, 2021] [12:39:37 PM PDT] <jeremyrubin> Well TBH if having heights released is going to cause people to do a simul UASF client, then maybe nacking height is prudent
[Tuesday, March 23, 2021] [12:39:59 PM PDT] <BlueMatt> jeremyrubin: heh, well cant disagree with that one...kinda defeats the whole point of ST, at least afaiu
[Tuesday, March 23, 2021] [1:07:21 PM PDT] <achow101> NACK to a uasf having any overlap in signaling with ST
[Tuesday, March 23, 2021] [1:07:33 PM PDT] <achow101> or literally any other activation method
[Tuesday, March 23, 2021] [1:08:02 PM PDT] <michaelfolkson> NACK to an incompatible UASF at same time as ST. That would be dumb too
[Tuesday, March 23, 2021] [1:08:13 PM PDT] <benthecarman81> imo It's good to have a UASF client ready if ST fails, they don't need to overlap however
[Tuesday, March 23, 2021] [1:18:57 PM PDT] <jeremyrubin> michaelfolkson: it is relevent because luke-jr nacked MTP ST and i've nacked height ST if it means there's going to be a PR push to do a UASF before ST
[Tuesday, March 23, 2021] [1:20:36 PM PDT] <jeremyrubin> michaelfolkson: no pure-technical nack. just that I don't think it has consensus since it seems that it is incentivizing a UASF client
[Sunday, March 28, 2021] [9:54:04 AM PDT] <michaelfolkson> Can you Approach NACK Andrew's PR so we can get this torture over with please jeremyrubin? We get enough Approach NACKs on both PRs and we can move on with UASF
[Sunday, March 28, 2021] [9:55:06 AM PDT] <jeremyrubin> I'm approach NACK UASF, so if you think that me approach NACKing something else is required for a UASF, then I will not NACK
[Sunday, March 28, 2021] [9:56:00 AM PDT] <michaelfolkson> I'm looking for a sufficient number of Approach NACKs on both Speedy Trial PRs and then I think no one can criticize us for moving on with UASF
[Tuesday, April 6, 2021] [8:37:42 AM PDT] <jeremyrubin> My approach NACK is over merging ST in core while valued contributors prepare a simultaneous UASF client. Maybe walk down the MAD [Mutually Assured Destruction] stance? Technically, either height or MTP can work fine for activation on mainnet, AJ introduced new ideas that make MTP relevent for discussion again
[Tuesday, April 6, 2021] [8:55:26 AM PDT] <luke-jr> [12:05:41] <michaelfolkson> I think once we get more NACKs we need to set a date for restarting the UASF discussion <-- no need to restart, just move forward