Hi Devs,

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

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

- 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.

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.

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 <version number> 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.

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?).

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.

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.

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.

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.