Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id AF0CBC001E for ; Wed, 12 Jan 2022 08:23:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 8B9056FB82 for ; Wed, 12 Jan 2022 08:23:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 0H-5u8yH8s2Y for ; Wed, 12 Jan 2022 08:23:35 +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 CEF2C6FB7A for ; Wed, 12 Jan 2022 08:23:34 +0000 (UTC) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20C8NVW7032203 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 12 Jan 2022 03:23:32 -0500 Received: by mail-lf1-f54.google.com with SMTP id m1so5428415lfq.4 for ; Wed, 12 Jan 2022 00:23:32 -0800 (PST) X-Gm-Message-State: AOAM531cxG+FnAkfrsBPVzOV7L+oSSQQP3vct/ixIdxqqQ8G9qyAlQKK RweIOvglORJYOOxiwGyqA7KWHv+aSKV+c4zsQss= X-Google-Smtp-Source: ABdhPJyU/kK0LkczmM9d4K+BWe9B2dE5UICNi2d4rKXJuLktibeUtXAsQcHiJ4ZTutfmBRXHB1qKxwJ7igR+khFlgeo= X-Received: by 2002:a05:6512:1054:: with SMTP id c20mr5955612lfb.247.1641975810882; Wed, 12 Jan 2022 00:23:30 -0800 (PST) MIME-Version: 1.0 From: Jeremy Date: Wed, 12 Jan 2022 00:23:19 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="000000000000f002fc05d55e4899" Subject: [bitcoin-dev] Summary of BIP-119 Meeting #1 Tuesday January 11th 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, 12 Jan 2022 08:23:36 -0000 --000000000000f002fc05d55e4899 Content-Type: text/plain; charset="UTF-8" Hi Devs, Below you'll find my summary of the BIP-119 Meeting held earlier today. Overall the meeting was pleasant although fast paced. Thank you all for attending and participating. I look forward to seeing (more of) you next time! Meeting notes available here: https://gnusha.org/ctv-bip-review/2022-01-11.log, please check my work that I've accurately reflected the opinions expressed. You'll also find the notes instructive to peruse if you wish to use it as a guide for reviewing the BIP. Cheers, Jeremy *In brief:* - CTV's design seems relatively uncontroversial/easy to comprehend. - The desirability / suitability of CTV for its use cases still seemed uncertain to participants. - Among participants, there seemed to be sentiment that if we are to stick to taproot speedy-trial like timelines, Springtime ('22, '23, ...) seems to make sense. - For the next meeting, the sessions will focus more heavily on applications and will be slower paced. *Detailed summary:* *First participants noted what they were excited for CTV to do.* Among participants in the meeting: There was strong interest expressed in the Vaults use case by a number of individuals. There was lighter interest in non-interactive channels and payment pools. There was strong skepticism expressed about congestion control; it was noted that non-interactive channels+congestion control was a strong motivator. *Then, BIP review began:* While reviewing the BIP: Quadratic hashing during validation, and how CTV should be immune to it via caching, was reviewed. The costs and lifetime of PrecomputedData caching was reviewed. A question was asked as to why the witness data was not in the CTV hash, which was explained that it could prevent signatures from being used with CTV. The half-spend problem was explained and CTV's mitigations against it were reviewed. CTV's usage of a NOP was reviewed; after CTV 6 upgradable NOPs would remain, it was pointed out that multibyte NOP10 could extend the NOP space indefinitely (since CTV only uses 32-byte arguments, CTV's NOP is only partly used). Only adding CTV to tapscript (and not segwit v0, bare script, p2sh) was discussed; no one expressed strongly that presence in legacy script was problematic if there was a use for it -- i.e., let the market decide (since some scripts are cheapest in bare script), although there seemed to be agreement that you'd usually want Taproot. It was clearly preferred that CTV use SHA256 and not RIPEMD160. How big interactive protocols can get without DoS was discussed. CTV makes non-interactive protocols possible, open question of if it matters. The bulk of the benefit of a batch is in the first 10 participants (90%), additional may not matter as much. It was agreed upon that CTV did at least seem to make protocols asynchronous and non-interactive, once participants agreed on what that terminology meant. A desire was expressed to see more batched openings done in Lightning to see if/how CTV might help. *bonus: Alex tweeted after the meeting about currently operational LN batched opens, without congestion control **https://twitter.com/alexbosworth/status/1481104624085917699 .* *Then, Code Review began.* First, the "main" BIP functionality commits were reviewed. The current state of code coverage was discussed & improvements on that. HandleMissingData remains difficult to code cover. CTV's policy discouraging rules before activation were discussed, and how this improves on prior soft forks not discouraging spends. The TODO in the caching heuristic was discussed. The history of the PrecomputedData caching heuristics was discussed, and how they became more aggressive under taproot and that this might be a minor regression. It was explained by the author that "TODO" meant someone could do something in the future, not that something must be done now. The bare CTV script type was discussed. The difference between legacy script validation and standardness was discussed. Bare CTV script does not (yet?) get it's own address type, but a standard output type is still needed for relaying from internal services. That it could be removed and added later was discussed, but that it causes difficulty for testing was also mentioned. Tests and test vectors were discussed. A non blocking action item was raised to make our hex json test vectors (for all Bitcoin) human readable was raised (otherwise, how do we know what they do?). *Then, discussion of the bug bounty began.* An offer was made to make the administration of the program through a tax deductible 501c3, Lincoln Network. Difficulties were discussed in practical administration of the program funds. Desire was expressed to reward more than just 'showstopping' bugs, but also strong reviews/minor issues/longer term maintenance. Desire was expressed for a covenants-only Scaling Bitcoin like event. Some discussion was had about bounties based around mutation testing, but it was not clear how that might work for CTV specifically. *Then, discussion of a release timelines began.* *this discussion was disclaimed to be about what might be feasible, less so the advisability of CTV in general.* Discussion was had around either merging unactivated consensus code for CTV ahead of the next feature freeze, delaying the next feature freeze slightly if that is too tight, or delaying CTV. The importance of backporting and relationship to merging unactivated code was discussed. Discussion was had around 'launch windows', and how, presupposing something like ST, late spring release, summer signaling, and early Nov activation seemed to be ideal. Such that if it cannot be done for this year, it might entail waiting +1 year to fit nicely with release schedules and major holidays. A preference for late spring/early summer signaling, similar to taproot, seemed uncontroversial. *Then, the main meeting ended. And the post-meeting began:* Some developers shared what their personal next steps were. A review of current tested ACKs was done. Kanzure forgot he implemented CTV Vaults 2 years ago :p A review of literature / resources to learn about alternative covenants. Activation mechanisms were discussed: Updates to BIP-119 make clear that deployment is through whatever has consensus, not necessarily ST. Participants during the meeting quite like UASF as an option, but not as a first option as it can be done in a follow-up release. -- @JeremyRubin --000000000000f002fc05d55e4899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Devs,

Below you= 'll find my summary of the BIP-119 Meeting held earlier=C2=A0today.

<= div class=3D"gmail_default">Overall the meeting was pleasant although fast = paced. Thank you all for attending and participating. I look forward to see= ing (more of) you next time!

Meeting notes available here:=C2=A0https://gnusha.org/ctv-bip-review/2022-01-11.log, please check my work= that I've accurately reflected the opinions expressed. You'll also= find the notes instructive to peruse if you wish to use it as a guide for = reviewing the BIP.

Cheers,

=
Jeremy

In brief:
- CTV's desi= gn seems relatively uncontroversial/easy to comprehend.
- The desirability / suitability of CTV for its use case= s still seemed uncertain to participants.
- Among participants, there seemed to be sentiment that if we are to s= tick to taproot speedy-trial like timelines, Springtime ('22, '23, = ...) seems to make sense.
- For the n= ext meeting, the sessions will focus more heavily on applications and will = be slower paced.

Detailed summary:

First participants= noted what they were excited for CTV to do.

Among participants i= n the meeting:
There was strong inter= est expressed in the Vaults use case by a number of individuals.
There was lighter interest in non-interactive c= hannels and payment pools.
There was strong skepticism expressed about congesti= on control; it was noted that non-interactive channels+congestion control w= as a strong motivator.

T= hen, BIP review began:

=
While reviewing the BIP:
Quadratic=C2=A0hashing during validation, and how CT= V should be immune to it via caching, was reviewed.
The costs and lifetime of PrecomputedData caching was review= ed.
A question was asked as to why th= e witness data was not in the CTV hash, which was explained that it could p= revent signatures from being used with CTV.
The half-spend problem was explained and CTV's mitigations again= st it were reviewed.

CTV's usage of a NOP was reviewed; after CTV= 6 upgradable NOPs would remain, it was pointed out that multibyte <vers= ion number> NOP10 could extend the NOP space indefinitely (since CTV onl= y uses 32-byte arguments, CTV's NOP is only partly used).
Only adding CTV to tapscript=C2=A0(and not segwit = v0, bare script, p2sh) was discussed; no one expressed strongly that presen= ce in legacy script was problematic if there was a use for it -- i.e., let = the market decide (since some scripts are cheapest in bare script), althoug= h there seemed to be agreement that you'd usually want Taproot.

I= t was clearly preferred that CTV use SHA256 and not RIPEMD160.

How bi= g interactive protocols can get without DoS was discussed. CTV makes non-in= teractive protocols possible, open question of if it matters. The bulk of t= he benefit of a batch is in the first 10 participants (90%), additional may= not matter as much. It was agreed upon that CTV did at least seem to make = protocols asynchronous and non-interactive, once participants agreed on wha= t that terminology meant. A desire was expressed to see more batched openin= gs done in Lightning to see if/how CTV might help. bonus: Alex tweeted a= fter the meeting about currently operational LN batched opens, without cong= estion control=C2=A0https://twitter.com/alexbosworth/status/14811046240= 85917699.

=
Then= , Code Review began.

= First, the "main" BIP functionality commits were reviewed.
<= div class=3D"gmail_default" style=3D"font-size:small">
The current state of code cove= rage was discussed & improvements on that. HandleMissingData remains di= fficult to code cover.
CTV's policy discouraging rules before activation were discusse= d, and how this improves on prior soft forks not discouraging spends.
=
The TODO in the cach= ing heuristic was discussed. The history of the PrecomputedData caching heu= ristics was discussed, and how they became more aggressive=C2=A0under tapro= ot and that this might be a minor regression. It was explained by the autho= r that "TODO" meant someone could do something in the future, not= that something must be done now.

The bare CTV script type was discussed. The difference between l= egacy script validation and standardness was discussed.
Bare CTV script does not (yet?) ge= t it's own address type, but a standard output type is still needed for= relaying from internal services.
That it could be removed and added later was discussed= , but that it causes difficulty for testing was also mentioned.

Tests and test vectors were discusse= d.
A non blocki= ng action item was raised to make our hex json test vectors (for all Bitcoi= n) human readable was raised (otherwise, how do we know what they do?).

Then, discussion of the b= ug bounty began.

An offer was made to make the administration of the program through a ta= x deductible 501c3, Lincoln Network.
Difficulties were discussed in practical administrati= on of the program funds.
Desire was expressed to reward more than just 'showstopping&#= 39; bugs, but also strong reviews/minor issues/longer term maintenance.
Desire was express= ed for a covenants-only Scaling Bitcoin like event.
Some discussion was had about bounties= based around mutation testing, but it was not clear how that might work fo= r CTV specifically.


<= /div>
Then, discussion of a release time= lines began.

this discussion was disclaimed to be about= what might be feasible, less so the advisability of CTV in general.

Discussion was had around either merging unactivated consensus c= ode for CTV ahead of the next feature freeze, delaying the next feature fre= eze slightly if that is too tight, or delaying CTV.
The importance of backporting a= nd relationship to merging=C2=A0unactivated code was discussed.
=
Discussion was had around 'launch wind= ows', and how, presupposing something like ST, late spring release, sum= mer signaling, and early Nov activation seemed to be ideal. Such that if it= cannot be done for this year, it might entail waiting=C2=A0+1 year to fit = nicely with release schedules and major holidays.
A preference for late spring/early summer signaling, similar t= o taproot, seemed uncontroversial.
<= br>

Then, the main meeting ended. And the post-meeting began:<= /div>

Some developers shared what their personal next steps were.
A review of current tested ACKs was don= e.
Kanzure forgot he implemented CTV = Vaults 2 years ago :p
A review of lit= erature / resources to learn about alternative covenants.

Activatio= n mechanisms were discussed:
Updates = to BIP-119 make clear that deployment is through whatever has consensus, no= t necessarily ST.
Participants during= the meeting quite like UASF as an option, but not as a first option as it = can be done in a follow-up release.
<= br>


--000000000000f002fc05d55e4899--