From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D8DCFC000A for ; Tue, 6 Apr 2021 21:31:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id BA5E2414E0 for ; Tue, 6 Apr 2021 21:31:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgPBC4gJmn_J for ; Tue, 6 Apr 2021 21:31:46 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id B759140F93 for ; Tue, 6 Apr 2021 21:31:45 +0000 (UTC) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 136LVhIs023632 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 6 Apr 2021 17:31:44 -0400 Received: by mail-il1-f169.google.com with SMTP id z9so14430825ilb.4 for ; Tue, 06 Apr 2021 14:31:44 -0700 (PDT) X-Gm-Message-State: AOAM533NEFeDRuk5o6V5CkNDG1mvRfZLv9gLtiQ7Zh075Yl0GDVaO1PA MP3dNeDa1FVUR7XgC2KXWL0QDWqtBo0scwBxRmo= X-Google-Smtp-Source: ABdhPJzG59x8t9ujuYPCGhxLT/Z2FWsrvtwfBgC2SEFMQK/Y6XWdvPAHGPwjIaq2zsVSKqHqSc8eOUhjtd/fGi+Ng1o= X-Received: by 2002:a05:6e02:1242:: with SMTP id j2mr233946ilq.105.1617744703405; Tue, 06 Apr 2021 14:31:43 -0700 (PDT) MIME-Version: 1.0 From: Jeremy Date: Tue, 6 Apr 2021 14:31:31 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="00000000000062441005bf548a73" Subject: [bitcoin-dev] Taproot Activation Meeting Notes, April 6th: The CoinFlip X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 21:31:48 -0000 --00000000000062441005bf548a73 Content-Type: text/plain; charset="UTF-8" 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] 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] At the same time, we have two PRs to look at [4/6/21 12:28] 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] I think the differences between MTP and height are less important than working towards a single PR to review [4/6/21 13:09] 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] 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] people selecting coinflip because they think the interest in timeline outweighs any individual perceived technical benefit [4/6/21 13:45] it's not a don't care, it's a recognition there are two decent proposals with different tradeoffs [4/6/21 13:45] and a desire to break stalemate on it mutually and voluntarily [4/6/21 13:49] 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] what copumpkin said [4/6/21 13:50] (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 --00000000000062441005bf548a73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bitcoin Developers,
=

The second fortnightly taproot activation meeting has just concluded. Belo= w are my notes:

1) On AJ's mods to MTP
=C2=A0=C2=A0 - luke-jr is still NACK any MTP related thing<= /div>
=C2=A0=C2=A0 - It is generally uncont= ested that the Mods are fine; that it should be LOT (via LAST_CHANCE) compa= tible
=C2=A0=C2=A0 - it does make MTP= a bit harder to review, but not unacceptably so
2) On selecting between MTP and Height
=C2=A0=C2=A0 - There are some benefits to MTPs
=C2=A0=C2=A0 - There are some benefits to Heights
=C2=A0=C2=A0 - Both are technically pr= obably OK to use for Taproot
=C2=A0= =C2=A0 - Both about as hard/easy to review (some think height has fewer edg= e conditions)
=C2=A0=C2=A0 - AJ a= nd Andrew Chow are going to see if they can unify approaches
3) Timeline + CoinFlip
=C2=A0=C2=A0 - Many present at the meeting preferred to work = together to compromise and reach consensus to stick to the timeline from th= e last meeting over either height or MTP.
=C2=A0=C2=A0 - as such a coinflip is being run via `bitcoin-cli getblo= ckhash $((678059+20)) | cut -b64 | grep -q '[02468ace]' && = echo MTP || echo height` (that's about 13 blocks from writing).
=C2=A0=C2=A0 - If it comes up MTP, contribut= ors mentioned below will work towards moving MTP forwards.
=C2=A0=C2=A0 - If it comes up height, contributors m= entioned below will work towards moving height forwards.
=C2=A0=C2=A0 - You can pre-commit to following this pat= h by responding in the next hour or so, or also choose to abide by it async=
=C2=A0=C2=A0 - If in the next day or= so, AJ and Andrew Chow reach a compromise between approaches that is compa= tible 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 approac= hes.
=C2=A0=C2=A0=C2=A0 - If this app= roach 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 emerge= nt 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
- jeremy= rubin

There were also several folks, anonymously, who said essentiall= y that they don't want to commit to a flip but if it works it works and= they'd roll with it.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small;color:#000000">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 f= ine 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.<= br>

[4/6/21 12:26] <jeremyrubin> We are super lucky that both a= chow101 and aj are such competent developers that we have not one but two f= antastic 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 se= ction I'd like to remind people to check dug-in opinions at the door, w= hat 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 t= o examine that favour either approach
[4/6/21 12:28] <jeremyrubin>= I think the differences between MTP and height are less important than wor= king towards a single PR to review
<= br>
[4/6/21 13:09] <harding> I = think both MTP and heights are fine for mainnet, so one of them having an a= dvantage for test networks seems worth considering.

[4/6/21 13:09] &l= t;rgrant> This topic seems to be winding down.=C2=A0 I'm hearing: th= at 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.=C2=A0 Coinflip seems to be winning.

[4/6/21 13:4= 5] <jeremyrubin> people selecting coinflip because they think the int= erest 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 mutua= lly and voluntarily

[4/6/21 13:49] <copumpkin> IMO coinflip is= more of an acknowledgment that the two CRs differ largely in shed color an= d 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] &l= t;copumpkin> (not to minimize the differences between them, but gotta ke= ep the big picture in mind and not die on hills that don't need dead pe= ople on them)

We have two good options, and coinflip is people agreei= ng to put aside minute preferences on two acceptable options for the big pi= cture. As such, I think that a coinflip is appropriately used in this circu= mstance, although I recognize the sentiment that some may feel it's tre= ating development a little too flippantly.

Rough consensus= and running code.

Best,
<= br>
Jeremy

--00000000000062441005bf548a73--