Re: [bitcoin-dev] Taproot Activation Meeting Notes, April 6th: The CoinFlip

[Jeremy <jlrubin@mit.edu>]

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

Update: the coin has flipped in favor of MTP

https://blockstream.info/block/00000000000000000000a6bcbf09849fe895b5d18ed884e8d558a57fc4f5e95c


Further, there seems to be some agreement between Andrew and AJ w.r.t.
reverting one of the changes AJ made recently (
https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-814494847),
resolving some of the contention between them for a MTP-based ST.

As such, I'm personally confident that if you want to spend your time
reviewing #21377, it has a very decent chance of accumulating sufficient
review and support from the community to be considered for a release in
accordance to the schedule from the last meeting. The changes in line with
Andrew and AJ's compromise are yet to be implemented, but they do not seem
to be complicated so you can probably expect AJ will implement and offer
them for review shortly (AJ if you're going on spring break let us know and
we can pick it up...).

Thanks to everyone and especially thanks to AJ and Andrew for all the hard
work they have put in preparing and evaluating these ideas. To outside
looking in, it might seem like there is contention between the two, but
they've been working together closely the whole time reviewing each other's
PRs and making tools and tests that make the whole thing safer anyways.
Let's all take a note from their book!

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Tue, Apr 6, 2021 at 2:31 PM Jeremy <jlrubin@mit.edu> wrote:

> Bitcoin Developers,
>
> The second fortnightly taproot activation meeting has just concluded.
> Below are my notes:
>
> 1) On AJ's mods to MTP
>    - luke-jr is still NACK any MTP related thing
>    - It is generally uncontested that the Mods are fine; that it should be
> LOT (via LAST_CHANCE) compatible
>    - it does make MTP a bit harder to review, but not unacceptably so
> 2) On selecting between MTP and Height
>    - There are some benefits to MTPs
>    - There are some benefits to Heights
>    - Both are technically probably OK to use for Taproot
>    - Both about as hard/easy to review (some think height has fewer edge
> conditions)
>    - AJ and Andrew Chow are going to see if they can unify approaches
> 3) Timeline + CoinFlip
>    - Many present at the meeting preferred to work together to compromise
> and reach consensus to stick to the timeline from the last meeting over
> either height or MTP.
>    - as such a coinflip is being run via `bitcoin-cli getblockhash
> $((678059+20)) | cut -b64 | grep -q '[02468ace]' && echo MTP || echo
> height` (that's about 13 blocks from writing).
>    - If it comes up MTP, contributors mentioned below will work towards
> moving MTP forwards.
>    - If it comes up height, contributors mentioned below will work towards
> moving height forwards.
>    - You can pre-commit to following this path by responding in the next
> hour or so, or also choose to abide by it async
>    - If in the next day or so, AJ and Andrew Chow reach a compromise
> between approaches that is compatible with the timeline of getting to a RC1
> with deployment, then that can be considered on its merits in preference of
> either of the existing approaches.
>     - If this approach fails at helping move towards consensus on an
> approach, then we will have to push back the timeline most likely for a
> core release (or an emergent group will have to offer a community release)
>
> The following folks in the meeting agreed to abide by the flip:
>
> - roasbeef
> - benthecarman
> - harding
> - jonatack
> - rgrant
> - copumpkin (in DM)
> - Emcy
> - jeremyrubin
>
> There were also several folks, anonymously, who said essentially that they
> don't want to commit to a flip but if it works it works and they'd roll
> with it.
>
> As noted, if you want to +1 on to coinflip before it settles, feel free to
> do in response here or IRC. It's also fine to just abide by it after the
> fact as well.
>
> ------------------
>
> Personal comment on coin flip: A coinflip seems like an odd choice for a
> technical decision. But let me excerpt some quotes from the meeting.
>
> [4/6/21 12:26] <jeremyrubin> We are super lucky that both achow101 and aj
> are such competent developers that we have not one but two fantastic PRs to
> look at
> [4/6/21 12:26] <jeremyrubin> At the same time, we have two PRs to look at
> [4/6/21 12:28] <jeremyrubin> In this section I'd like to remind people to
> check dug-in opinions at the door, what matters here is if we can agree on
> a plan of action and get the bulk of everyone on the same page. That said,
> there are nuanced technical points to examine that favour either approach
> [4/6/21 12:28] <jeremyrubin> I think the differences between MTP and
> height are less important than working towards a single PR to review
>
> [4/6/21 13:09] <harding> I think both MTP and heights are fine for
> mainnet, so one of them having an advantage for test networks seems worth
> considering.
>
> [4/6/21 13:09] <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.
>
> [4/6/21 13:45] <jeremyrubin> people selecting coinflip because they think
> the interest in timeline outweighs any individual perceived technical
> benefit
> [4/6/21 13:45] <jeremyrubin> it's not a don't care, it's a recognition
> there are two decent proposals with different tradeoffs
> [4/6/21 13:45] <jeremyrubin> and a desire to break stalemate on it
> mutually and voluntarily
>
> [4/6/21 13:49] <copumpkin> IMO coinflip is more of an acknowledgment that
> the two CRs differ largely in shed color and that we all want the shed, and
> don't care as much about its color
> [4/6/21 13:49] <BlueMatt> what copumpkin said
> [4/6/21 13:50] <copumpkin> (not to minimize the differences between them,
> but gotta keep the big picture in mind and not die on hills that don't need
> dead people on them)
>
> We have two good options, and coinflip is people agreeing to put aside
> minute preferences on two acceptable options for the big picture. As such,
> I think that a coinflip is appropriately used in this circumstance,
> although I recognize the sentiment that some may feel it's treating
> development a little too *flippantly*.
>
> Rough consensus and running code.
>
> Best,
>
> Jeremy
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>

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