* [bitcoin-dev] Summary of BIP-119 Meeting #1 Tuesday January 11th
@ 2022-01-12 8:23 Jeremy
0 siblings, 0 replies; only message in thread
From: Jeremy @ 2022-01-12 8:23 UTC (permalink / raw)
To: Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 6563 bytes --]
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 <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
<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 <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 15374 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2022-01-12 8:23 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-12 8:23 [bitcoin-dev] Summary of BIP-119 Meeting #1 Tuesday January 11th Jeremy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox