summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy Rubin <jeremy.l.rubin@gmail.com>2022-02-09 00:53:12 -0800
committerbitcoindev <bitcoindev@gnusha.org>2022-02-09 08:53:28 +0000
commitc1807ddac343698e264703e7c0e2e6ccaf1bd789 (patch)
tree1cea6a53cb9db0d3bc895a5cfe5600058be8d6a2
parenteed724cf48762d71a4115aa57d2ac3fc9e12533b (diff)
downloadpi-bitcoindev-c1807ddac343698e264703e7c0e2e6ccaf1bd789.tar.gz
pi-bitcoindev-c1807ddac343698e264703e7c0e2e6ccaf1bd789.zip
[bitcoin-dev] CTV Meeting Notes #3
-rw-r--r--53/e3fc2e0e964a98cd879476b6d1fcfab32d3335258
1 files changed, 258 insertions, 0 deletions
diff --git a/53/e3fc2e0e964a98cd879476b6d1fcfab32d3335 b/53/e3fc2e0e964a98cd879476b6d1fcfab32d3335
new file mode 100644
index 000000000..00d5f9f67
--- /dev/null
+++ b/53/e3fc2e0e964a98cd879476b6d1fcfab32d3335
@@ -0,0 +1,258 @@
+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--
+