path: root/53/e3fc2e0e964a98cd879476b6d1fcfab32d3335

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5A5EEC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Feb 2022 08:53:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3DC65606B0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Feb 2022 08:53:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 JD1zSZ3bQT7n
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Feb 2022 08:53:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com
 [IPv6:2a00:1450:4864:20::229])
 by smtp3.osuosl.org (Postfix) with ESMTPS id CFBFC60674
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  9 Feb 2022 08:53:26 +0000 (UTC)
Received: by mail-lj1-x229.google.com with SMTP id bx31so2491546ljb.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 09 Feb 2022 00:53:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:from:date:message-id:subject:to;
 bh=NMhaFVFk8ciyyy/otkWIT9WGsBW3mJelcpxKs4Gc43Q=;
 b=UiPM8evIt3opXGwiYC6lfOATTm+WoW9vI1yipAsvZrUI/nfci1WsBSRMnyw6/TwtXG
 8teExlEPu7h/ZzYwKMWEsMdbmlLPbCFLhgD8iHJruyLKb2eT3/TjjzGa+k66nOtKg8Sm
 IGxuSXOzP4WFCDQk1Dri9vOlWZhBlzSeJEszn0SCLy+7GP6q0MGSSkWvltNydPW6SfLq
 74+P6U/72O70hGHdFo/a+rZ54F1x0UixU+3N6eMLrChtspvGCebDYYEt3fikLPp3Gvqi
 Vthl0OhnxM39Eo5WTJMFB/rO2h0N3QXwvIC/ZnAVTPxy2Sq3nOTDdHX8yuIrK5hd3NXi
 ydNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=NMhaFVFk8ciyyy/otkWIT9WGsBW3mJelcpxKs4Gc43Q=;
 b=kBWlshUXdhgMB6dzJT09pqaqGQBjGSYfV1ZkAAlXhL51ig7TpZZvk/XAgXRQEk/eEj
 N9d9z3AFBtm9X+QTZro31jl8H7ytJt6cCWQfEcAJwYFURpaFeuzlbh39kZmfHQzkhFS8
 v0QMsr6nd0/NrLVBfJxc5lq6O4bi/D+uqoU/K8FFcRcTB2aCdcrE689ihzkg+QLisKvy
 mmuw6YgREbI53xQVcQi8OnJh3DaeHf+4EiXz9OeVQKffZb+z7rK7jegd0fbnbmyx+C5Y
 PqTHRWeenW95pbQqrSv1gEv55Ha/nA3YIBYYYlF4oqA6M1ixnzeScbYXU3k/3U+RsGmv
 mt3w==
X-Gm-Message-State: AOAM531pRkMtAu4FPW3zuK9wpbUWvByNmniYWI9+zVQFG/UNia5YKZDl
 0NpckwDnUDT2e3IsAZLx0RCRAjyg9MCbRHngqvlbyfwyHSK+Ug==
X-Google-Smtp-Source: ABdhPJxUmG2BF39BsfS1AWeF2+LB1Bzvbudfd6Hehpy40hexSPU7/3/XynjRdybCaToRS3juoHzjkU/Z88Epj5qIE4s=
X-Received: by 2002:a2e:834c:: with SMTP id l12mr872262ljh.81.1644396803728;
 Wed, 09 Feb 2022 00:53:23 -0800 (PST)
MIME-Version: 1.0
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Wed, 9 Feb 2022 00:53:12 -0800
Message-ID: <CAD5xwhhPp9+woDTJW8Mu+sgGP-468krH5oXGw_On0AHP2oyVfA@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005b27cb05d791f730"
Subject: [bitcoin-dev] CTV Meeting Notes #3
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, 09 Feb 2022 08:53:28 -0000

--0000000000005b27cb05d791f730
Content-Type: text/plain; charset="UTF-8"

Bitcoin Developers,

The Third CTV meeting was held earlier today (Tuesday February 8th, 2022).
You can find the meeting log here:
https://gnusha.org/ctv-bip-review/2022-02-08.log

A best-effort summary:

- Not much new to report on the Bounty
- Non Interactive Lightning Channel Opens
  Non interactive lightning Channel opens seems to work!
  There are questions around being able operate a channel in a "unipolar"
way for routing with the receiver's key offline, as HTLCs might require
sync revocation. This is orthogonal to the opening of the channels.
- DLCs w/ CTV
  DLCs built with CTV does seem to be a "key enabler" for DLCs.
  The non interactivity provides a dramatic speedup (30x - 300x depending
on multi-oracle setup)
  Changes the client/server setup enable new use cases to explore, and
simplify the spec substantially.
  Backfilling lets clients commit to the DLC faster and lazily backfill at
cost of state storage.
  For M-N oracles, precompiling N choose M groups + musig'ing the
attestation points can possibly save some witness space because
log2(N)*32 + N*32 > log2(N*(N choose M))*32 for many values of N and M.
- Pathcoin
  Not well understood yet concretely.
  Seems like the API of a "a coin that 1-of-N can spend" shared by N is
new/unique and not something LN can do (which always requires N online to
sign txns)
  Binary expansion of coins could allow arbitrary value transfer (binary
expansion can live in a CTV tree too).
  Best way to think of Pathcoin at this point is an important theoretical
result that should open up new exploration/improvement
- TXHash
  Main concerns: more complexity, potential for recursion, script size
overhead
- Soft Forks, Generally
  Big question: Are the fork processes themselves (e.g., BIP9/8/ST
activiations) riskier than the upgrades (CTV)?
  On the one hand, validation rules are something we have to live with
forever so they should be riskier. Soft fork rules and coordination might
be bad, but after activation they go away.
  On the other hand, we can "prove" a technical upgrade correct, but
soft-fork signalling requires unprovable user behavior and coordination
(e.g., actually upgrading).
  If you perceive the forking mechanism as high risk, it makes sense to
make the upgrades have as much content as possible since you need to
justify the high risk.
  If you perceive the forking mechanism as low risk, it is fine to make the
upgrades smaller and easier to prove safe since there's not a high cost to
forking.
- Elements CTV Emulation
  Seems to be workable.
  Questionable if any of the use cases one might want CTV for (Lightning,
DLCs, Vaults) would have much demand on Liquid today.

Feel free to correct me where I've not represented perspectives decently,
as always the logs are the only true summary.

Best,

Jeremy

--
@JeremyRubin <https://twitter.com/JeremyRubin>

--0000000000005b27cb05d791f730
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">Bitcoin Developers,</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"=
>The Third CTV meeting was held earlier today (Tuesday February 8th, 2022).=
=C2=A0 You can find the meeting log here:=C2=A0<a href=3D"https://gnusha.or=
g/ctv-bip-review/2022-02-08.log">https://gnusha.org/ctv-bip-review/2022-02-=
08.log</a></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000">A best-effort summary:</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000">- Not much new to report on t=
he Bounty</div><div class=3D"gmail_default" style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:#000000">- Non Interactive Lightning=
 Channel Opens</div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 Non interactive=
 lightning Channel opens seems to work!</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0">=C2=A0 There are questions around being able operate a channel in a &quo=
t;unipolar&quot; way for routing with the receiver&#39;s key offline, as HT=
LCs might require sync revocation. This is orthogonal to the opening of the=
 channels.</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000">- DLCs w/ CTV</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000">=C2=A0 DLCs built with CTV does seem to be a &quo=
t;key enabler&quot; for DLCs.</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 =
The non interactivity=C2=A0provides a dramatic speedup (30x - 300x dependin=
g on multi-oracle setup)</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 Chang=
es the client/server setup enable new use cases to explore, and simplify th=
e spec substantially.</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 Backfill=
ing lets clients commit to the DLC faster and lazily backfill at cost of st=
ate storage.</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:#000000">=C2=A0 For M-N oracles, =
precompiling N choose M groups=C2=A0+ musig&#39;ing the attestation points =
can possibly save some witness space because log2(N)*32=C2=A0+ N*32 &gt; lo=
g2(N*(N choose M))*32 for many values of N and M.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000">- Pathcoin</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 Not we=
ll understood yet concretely.</div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 =
Seems like the API of a &quot;a coin that 1-of-N can spend&quot; shared by =
N is new/unique and not something LN can do (which always requires N online=
 to sign txns)</div><div class=3D"gmail_default" style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:#000000"><div class=3D"gmail_de=
fault">=C2=A0 Binary expansion of coins could allow arbitrary value transfe=
r (binary expansion can live in a CTV tree too).</div></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:#000000">=C2=A0 Best way to think of Pathcoin at this point is an =
important theoretical result that should open up new exploration/improvemen=
t</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000">- TXHash</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:#000000">=C2=A0 Main concerns: more complexity, potential for recursion,=
 script size overhead</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000">- Soft Forks, G=
enerally</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">=C2=A0 Big question: Are the=
 fork processes themselves (e.g., BIP9/8/ST activiations) riskier than the =
upgrades (CTV)?</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 On the one han=
d, validation rules are something we have to live with forever so they shou=
ld be riskier. Soft fork rules and coordination might be bad, but after act=
ivation they go away.</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 On the o=
ther hand, we can &quot;prove&quot; a technical upgrade correct, but soft-f=
ork signalling requires unprovable user behavior and coordination (e.g., ac=
tually upgrading).</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:#000000">=C2=A0 If you perc=
eive the forking mechanism as high risk, it makes sense to make the upgrade=
s have as much content as possible since you need to justify the high risk.=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:#000000">=C2=A0 If you perceive the forking m=
echanism as low risk, it is fine to make the upgrades smaller and easier to=
 prove safe since there&#39;s not a high cost to forking.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">- Elements CTV Emulation</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:#000000">=C2=A0 Seems to be workable.</div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0">=C2=A0 Questionable if any of the use cases one might want CTV for (Ligh=
tning, DLCs, Vaults) would have much demand on Liquid today.</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Feel fre=
e to correct me where I&#39;ve not represented perspectives decently, as al=
ways the logs are the only true summary.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">Best,</div><div class=3D"gma=
il_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">Jeremy</div><br =
clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmai=
l=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com=
/JeremyRubin" target=3D"_blank">@JeremyRubin</a><br></div></div></div></div=
>

--0000000000005b27cb05d791f730--