path: root/8c/9db3b93e98393d9f8bcae9d661907bf18743db

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AF0CBC001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Wed, 12 Jan 2022 03:23:32 -0500
Received: by mail-lf1-f54.google.com with SMTP id m1so5428415lfq.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <jlrubin@mit.edu>
Date: Wed, 12 Jan 2022 00:23:19 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhjm6AHEdXYrfmG08x8Hft4Jehjppd7GLaudmBhQ_FH=A@mail.gmail.com>
Message-ID: <CAD5xwhhjm6AHEdXYrfmG08x8Hft4Jehjppd7GLaudmBhQ_FH=A@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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>

--000000000000f002fc05d55e4899
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Devs,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Below you=
&#39;ll find my summary of the BIP-119 Meeting held earlier=C2=A0today.</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:#000000"><div class=3D"gmail_default"><br></div><=
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!</div><div class=3D"gmail_default"><br></div></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:#000000">Meeting notes available here:=C2=A0<a =
href=3D"https://gnusha.org/ctv-bip-review/2022-01-11.log" target=3D"_blank"=
>https://gnusha.org/ctv-bip-review/2022-01-11.log</a>, please check my work=
 that I&#39;ve accurately reflected the opinions expressed. You&#39;ll also=
 find the notes instructive to peruse if you wish to use it as a guide for =
reviewing the BIP.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">Cheers,</div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br>=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">Jeremy</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000"><div class=3D"gmail_default"><div class=3D"gmail_default"><br></di=
v><div class=3D"gmail_default"><b>In brief:</b></div></div>- CTV&#39;s desi=
gn seems relatively uncontroversial/easy to comprehend.</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:#000000">- The desirability / suitability of CTV for its use case=
s still seemed uncertain to participants.</div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000=
000">- Among participants, there seemed to be sentiment that if we are to s=
tick to taproot speedy-trial like timelines, Springtime (&#39;22, &#39;23, =
...) seems to make sense.</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:#000000">- For the n=
ext meeting, the sessions will focus more heavily on applications and will =
be slower paced.</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><b>Detailed summary:</b></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><b>First participants=
 noted what they were excited for CTV to do.</b></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000">Among participants i=
n the meeting:</div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000">There was strong inter=
est expressed in the Vaults use case by a number of individuals.</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:#000000">There was lighter interest in non-interactive c=
hannels and payment pools.<br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><div c=
lass=3D"gmail_default">There was strong skepticism expressed about congesti=
on control; it was noted that non-interactive channels+congestion control w=
as a strong motivator.</div><br></div><div class=3D"gmail_default" style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><b>T=
hen, BIP review began:</b></div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">While reviewing the BIP:</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">Quadratic=C2=A0hashing during validation, and how CT=
V should be immune to it via caching, was reviewed.</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000">The costs and lifetime of PrecomputedData caching was review=
ed.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000">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.</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0=
00000">The half-spend problem was explained and CTV&#39;s mitigations again=
st it were reviewed.</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:#000000">CTV&#39;s usage of a NOP was reviewed; after CTV=
 6 upgradable NOPs would remain, it was pointed out that multibyte &lt;vers=
ion number&gt; NOP10 could extend the NOP space indefinitely (since CTV onl=
y uses 32-byte arguments, CTV&#39;s NOP is only partly used).</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000">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&#39;d usually want Taproot.</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I=
t was clearly preferred that CTV use SHA256 and not RIPEMD160.</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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. <b>bonus: Alex tweeted a=
fter the meeting about currently operational LN batched opens, without cong=
estion control=C2=A0</b><span style=3D"font-family:Arial,Helvetica,sans-ser=
if;color:rgb(34,34,34)"><b><a href=3D"https://twitter.com/alexbosworth/stat=
us/1481104624085917699">https://twitter.com/alexbosworth/status/14811046240=
85917699</a>.</b></span></div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><span style=
=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><b><br></b>=
</span></div><div class=3D"gmail_default" style=3D"font-size:small"><b>Then=
, Code Review began.</b></div><div class=3D"gmail_default" style=3D"font-si=
ze:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small">=
First, the &quot;main&quot; BIP functionality commits were reviewed.</div><=
div class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=
=3D"gmail_default" style=3D"font-size:small">The current state of code cove=
rage was discussed &amp; improvements on that. HandleMissingData remains di=
fficult to code cover.</div><div class=3D"gmail_default" style=3D"font-size=
:small">CTV&#39;s policy discouraging rules before activation were discusse=
d, and how this improves on prior soft forks not discouraging spends.</div>=
<div class=3D"gmail_default" style=3D"font-size:small">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 &quot;TODO&quot; meant someone could do something in the future, not=
 that something must be done now.</div><div class=3D"gmail_default" style=
=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-s=
ize:small">The bare CTV script type was discussed. The difference between l=
egacy script validation and standardness was discussed.</div><div class=3D"=
gmail_default" style=3D"font-size:small">Bare CTV script does not (yet?) ge=
t it&#39;s own address type, but a standard output type is still needed for=
 relaying from internal services.</div><div class=3D"gmail_default" style=
=3D"font-size:small">That it could be removed and added later was discussed=
, but that it causes difficulty for testing was also mentioned.</div><div c=
lass=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gm=
ail_default" style=3D"font-size:small">Tests and test vectors were discusse=
d.</div><div class=3D"gmail_default" style=3D"font-size:small">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?).</di=
v><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-size:small"><b>Then, discussion of the b=
ug bounty began.</b></div><div class=3D"gmail_default" style=3D"font-size:s=
mall"><b><br></b></div><div class=3D"gmail_default" style=3D"font-size:smal=
l">An offer was made to make the administration of the program through a ta=
x deductible 501c3, Lincoln Network.</div><div class=3D"gmail_default" styl=
e=3D"font-size:small">Difficulties were discussed in practical administrati=
on of the program funds.</div><div class=3D"gmail_default" style=3D"font-si=
ze:small">Desire was expressed to reward more than just &#39;showstopping&#=
39; bugs, but also strong reviews/minor issues/longer term maintenance.</di=
v><div class=3D"gmail_default" style=3D"font-size:small">Desire was express=
ed for a covenants-only Scaling Bitcoin like event.</div><div class=3D"gmai=
l_default" style=3D"font-size:small">Some discussion was had about bounties=
 based around mutation testing, but it was not clear how that might work fo=
r CTV specifically.</div><div class=3D"gmail_default" style=3D"font-size:sm=
all"><br></div><div class=3D"gmail_default" style=3D"font-size:small"><br><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><b>Then, discussion of a release time=
lines began.</b></div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><b><br></b></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:#000000"><i>this discussion was disclaimed to be about=
 what might be feasible, less so the advisability of CTV in general.</i></d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000"><b><br></b></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">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.</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><div class=3D"gmail_default">The importance of backporting a=
nd relationship to merging=C2=A0unactivated code was discussed.</div></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000">Discussion was had around &#39;launch wind=
ows&#39;, 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.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">A preference for late spring/early summer signaling, similar t=
o taproot, seemed uncontroversial.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:#000000"><b>Then, the main meeting ended. And the post-meeting began:</b><=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><b><br></b></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">Some developers shared what their personal next steps were.</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000">A review of current tested ACKs was don=
e.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:#000000">Kanzure forgot he implemented CTV =
Vaults 2 years ago :p</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000">A review of lit=
erature / resources to learn about alternative covenants.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Activatio=
n mechanisms were discussed:</div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Updates =
to BIP-119 make clear that deployment is through whatever has consensus, no=
t necessarily ST.</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><=
br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:#000000"><br></div><br clear=3D"all"><div>=
<div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signatur=
e"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" targe=
t=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" ta=
rget=3D"_blank"></a></div></div></div></div>

--000000000000f002fc05d55e4899--