diff options
author | Jeremy Rubin <jeremy.l.rubin@gmail.com> | 2022-02-09 00:53:12 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-09 08:53:28 +0000 |
commit | c1807ddac343698e264703e7c0e2e6ccaf1bd789 (patch) | |
tree | 1cea6a53cb9db0d3bc895a5cfe5600058be8d6a2 | |
parent | eed724cf48762d71a4115aa57d2ac3fc9e12533b (diff) | |
download | pi-bitcoindev-c1807ddac343698e264703e7c0e2e6ccaf1bd789.tar.gz pi-bitcoindev-c1807ddac343698e264703e7c0e2e6ccaf1bd789.zip |
[bitcoin-dev] CTV Meeting Notes #3
-rw-r--r-- | 53/e3fc2e0e964a98cd879476b6d1fcfab32d3335 | 258 |
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" way for routing with the receiver'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" 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'ing the attestation points = +can possibly save some witness space because log2(N)*32=C2=A0+ N*32 > 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 "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)</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 "prove" 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'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'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-- + |