Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 56D9CC000A for ; Wed, 7 Apr 2021 00:02:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 36EB660662 for ; Wed, 7 Apr 2021 00:02:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_DOTEDU_SUSP_URI=2.999, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAG6lRGhXQQD for ; Wed, 7 Apr 2021 00:02:49 +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 smtp3.osuosl.org (Postfix) with ESMTPS id 5748B6062F for ; Wed, 7 Apr 2021 00:02:49 +0000 (UTC) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13702lOQ010413 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 6 Apr 2021 20:02:47 -0400 Received: by mail-io1-f42.google.com with SMTP id j26so12263270iog.13 for ; Tue, 06 Apr 2021 17:02:47 -0700 (PDT) X-Gm-Message-State: AOAM5317QDOlxPTGDghuM5AbQPRRpaNDl5ousrxW/zbqY+ORd2y6GUkY kneofM0APFdwrg0V66deVLx+0IjqFxIvl2XB/lU= X-Google-Smtp-Source: ABdhPJzhDvsm3zx5fyVzfl6oaVAW8au3qdtEL9WV/DMspEGeLdLAAabZGq637AspOtjDgwmURxkeKCRbi6RsfMORDhM= X-Received: by 2002:a05:6638:391:: with SMTP id y17mr679864jap.21.1617753767056; Tue, 06 Apr 2021 17:02:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Tue, 6 Apr 2021 17:02:35 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="0000000000009e98cb05bf56a6f5" Cc: Bitcoin development mailing list Subject: Re: [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: Wed, 07 Apr 2021 00:02:51 -0000 --0000000000009e98cb05bf56a6f5 Content-Type: text/plain; charset="UTF-8" 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 On Tue, Apr 6, 2021 at 2:31 PM Jeremy 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] 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 > > --0000000000009e98cb05bf56a6f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= /div>
Further, there se= ems 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/213= 77#issuecomment-814494847), resolving some of the contention between th= em for a MTP-based ST.

As such, I'm personally confiden= t that if you want to spend your time reviewing #21377, it has a very decen= t chance of accumulating sufficient review and support from the community t= o be considered for a release in accordance to the schedule from the last m= eeting. 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 th= ey've been working together closely the whole time reviewing each other= 's PRs and making tools and tests that make the whole thing safer anywa= ys. Let's all take a note from their book!

Best,

Jeremy


On Tue, = Apr 6, 2021 at 2:31 PM Jeremy <jlrubi= n@mit.edu> wrote:
Bitcoin Dev= elopers,

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

1) On AJ's mods to = MTP
=C2=A0=C2=A0 - luke-jr is stil= l NACK any MTP related thing
=C2= =A0=C2=A0 - It is generally uncontested that the Mods are fine; that it sho= uld be LOT (via LAST_CHANCE) compatible
=C2=A0=C2=A0 - it does make MTP a bit harder to review, but not unacc= eptably so
2) On selecting between= MTP and Height
=C2=A0=C2=A0 - The= re are some benefits to MTPs
=C2= =A0=C2=A0 - There are some benefits to Heights
=C2=A0=C2=A0 - Both are technically probably OK to use for Tap= root
=C2=A0=C2=A0 - Both about as = hard/easy to review (some think height has fewer edge conditions)
=
=C2=A0=C2=A0 - AJ and Andrew Chow are g= oing 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 the last meeti= ng over either height or MTP.
=C2= =A0=C2=A0 - 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).
=C2=A0=C2=A0 - If it comes up MTP, contributors m= entioned below will work towards moving MTP forwards.
=C2=A0=C2=A0 - If it comes up height, contributors ment= ioned 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 co= mpatible with the timeline of getting to a RC1 with deployment, then that c= an be considered on its merits in preference of either of the existing appr= oaches.
=C2=A0=C2=A0=C2=A0 - If th= is 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 foll= owing folks in the meeting agreed to abide by the flip:

- roasb= eef
- benthecarman
- hardi= ng
- jonatack
- rgrant
- co= pumpkin (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, fe= el free to do in response here or IRC. It's also fine to just abide by = it after the fact as well.
------------------

P= ersonal comment on coin flip: A coinflip seems like an odd choice for a tec= hnical decision. But let me excerpt some quotes from the meeting.
=

[4/6/21 12:26] <jeremyrubin> We are super lucky that both acho= w101 and aj are such competent developers that we have not one but two fant= astic 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 point= s to examine that favour either approach
[4/6/21 12:28] <jeremyrubin&= gt; I think the differences between MTP and height are less important than = working towards a single PR to review

[4/6/21 13:09] <hardin= g> I think both MTP and heights are fine for mainnet, so one of them hav= ing an advantage for test networks seems worth considering.

[4/= 6/21 13:09] <rgrant> This topic seems to be winding down.=C2=A0 I'= ;m hearing: that signet configuration isn't a dealbreaker but there is = technical debt incurred if we ignore it; MTP-based activation (read: celebr= ation 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:45] <jeremyrubin> people selecting coinflip becaus= e they think the interest in timeline outweighs any individual perceived te= chnical benefit
[4/6/21 13:45] <jeremyrubin> it's not a don= 9;t care, it's a recognition there are two decent proposals with differ= ent tradeoffs
[4/6/21 13:45] <jeremyrubin> and a desire to break s= talemate on it mutually and voluntarily

[4/6/21 13:49] <cop= umpkin> IMO coinflip is more of an acknowledgment that the two CRs diffe= r largely in shed color and that we all want the shed, and don't care a= s much about its color
[4/6/21= 13:49] <BlueMatt> what copumpkin said
[4/6/21 13:50] <copumpkin> (not to minimize the differ= ences between them, but gotta keep the big picture in mind and not die on h= ills 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 coinfl= ip is appropriately used in this circumstance, although I recognize the sen= timent that some may feel it's treating development a little too fli= ppantly.

Rough consensus and running code.

Best,

Jeremy

--0000000000009e98cb05bf56a6f5--