diff options
| author | Jeremy <jlrubin@mit.edu> | 2022-01-28 09:21:09 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-28 17:21:25 +0000 |
| commit | 01db9b92a3eb3692266d01a1e1959717f17b1f2f (patch) | |
| tree | 67f8165ca929c23bd9cdd47ea5e454217ec8b795 | |
| parent | d95b778f21adbacff4a12cd06db32715d55b9c01 (diff) | |
| download | pi-bitcoindev-01db9b92a3eb3692266d01a1e1959717f17b1f2f.tar.gz pi-bitcoindev-01db9b92a3eb3692266d01a1e1959717f17b1f2f.zip | |
Re: [bitcoin-dev] CTV dramatically improves DLCs
| -rw-r--r-- | d0/b3c64e4a3eb1cab5e67d9396fe0ccd3b62996d | 287 |
1 files changed, 287 insertions, 0 deletions
diff --git a/d0/b3c64e4a3eb1cab5e67d9396fe0ccd3b62996d b/d0/b3c64e4a3eb1cab5e67d9396fe0ccd3b62996d new file mode 100644 index 000000000..f50b052a7 --- /dev/null +++ b/d0/b3c64e4a3eb1cab5e67d9396fe0ccd3b62996d @@ -0,0 +1,287 @@ +Return-Path: <jlrubin@mit.edu> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id A0239C000B + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 17:21:25 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 88FE784DF6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 17:21:25 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -4.2 +X-Spam-Level: +X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, + RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 7-Lbqg8UlQfT + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 17:21:24 +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 smtp1.osuosl.org (Postfix) with ESMTPS id 304C684DF4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 17:21:24 +0000 (UTC) +Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com + [209.85.167.41]) (authenticated bits=0) + (User authenticated as jlrubin@ATHENA.MIT.EDU) + by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20SHLL3D011370 + (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) + for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 28 Jan 2022 12:21:22 -0500 +Received: by mail-lf1-f41.google.com with SMTP id x7so13109036lfu.8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Jan 2022 09:21:22 -0800 (PST) +X-Gm-Message-State: AOAM533qnJcbb++TEs9vtmDzQryKFQR1iqNM3aVwOrbouZrcqoJOQw7O + C7dM9ogrO6fqh/4ng9CV/jR7X9BiBa9yhCulWGg= +X-Google-Smtp-Source: ABdhPJxHH6KP+AwE5tjGXx4pS2zsD4hDiHaljvq8F71FVjWIMPl1xoP5bSmwMRKrC6nxZuNVO/UVuBAZbxjBWx/5xAU= +X-Received: by 2002:a05:6512:21c2:: with SMTP id + d2mr6722969lft.247.1643390480903; + Fri, 28 Jan 2022 09:21:20 -0800 (PST) +MIME-Version: 1.0 +References: <CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com> +In-Reply-To: <CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com> +From: Jeremy <jlrubin@mit.edu> +Date: Fri, 28 Jan 2022 09:21:09 -0800 +X-Gmail-Original-Message-ID: <CAD5xwhiJiopwH87Bn+yq_0-XXSJYOtNzUg4JCaYwuj=oo9CacA@mail.gmail.com> +Message-ID: <CAD5xwhiJiopwH87Bn+yq_0-XXSJYOtNzUg4JCaYwuj=oo9CacA@mail.gmail.com> +To: Lloyd Fournier <lloyd.fourn@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="000000000000d7727705d6a7a99f" +Cc: dlc-dev@mailmanlists.org +Subject: Re: [bitcoin-dev] CTV dramatically improves DLCs +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: Fri, 28 Jan 2022 17:21:25 -0000 + +--000000000000d7727705d6a7a99f +Content-Type: text/plain; charset="UTF-8" + +Lloyd, + +This is an excellent write up, the idea and benefits are clear. + +Is it correct that in the case of a 3/5th threshold it is a total 10x * 30x += 300x improvement? Quite impressive. + +I have a few notes of possible added benefits / features of DLCs with CTV: + +1) CTV also enables a "trustless timeout" branch, whereby you can have a +failover claim that returns funds to both sides. + +There are a few ways to do this: + +A) The simplest is just an oracle-free <STH(timeout tx)> CTV whereby the +timeout transaction has an absolute/relative timelock after the creation of +the DLC in question. + +B) An alternative approach I like is to have the base DLC have a branch +`<STH(begin timeout)> CTV` which pays into a DLC that is the exact same +except it removes the just-used branch and replaces it with `<STH(timeout +tx)> CTV` which contains a relative timelock R for the desired amount of +time to resolve. This has the advantage of always guaranteeing at least R +amount of time since the Oracles have been claimed to be non-live to +"return funds" to parties participating + + +2) CTV DLCs are non-interactive asynchronously third-party unilaterally +creatable. + +What I mean by this is that it is possible for a single party to create a +DLC on behalf of another user since there is no required per-instance +pre-signing or randomly generated state. E.g., if Alice wants to create a +DLC with Bob, and knows the contract details, oracles, and a key for Bob, +she can create the contract and pay to it unilaterally as a payment to Bob. + +This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can +also be constructed and then sent (along with a specific amount) to a third +party service (such as an exchange or Lightning node) to create DLCs +without requiring the third party service to do anything other than make +the payment as requested. + + +3) CTV DLCs can be composed in interesting ways + +Options over DLCs open up many exciting types of instrument where Alice can +do things like: +A) Create a Option expiring in 1 week where Bob can add funds to pay a +premium and "Open" a DLC on an outcome closing in 1 year +B) Create an Option expiring in 1 week where one-of-many Bobs can pay the +premium (on-chain DEX?). + + See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete stuff +around this. + +There are also opportunities for perpetual-like contracts where you could +combine into one logical DLC 12 DLCs closing 1 per month that can either be +payed out all at once at the end of the year, or profit pulled out +partially at any time earlier. + +4) This satisfies (I think?) my request to make DLCs expressible as Sapio +contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/ + +5) An additional performance improvement can be had for iterative DLCs in +Lightning where you might trade over a fixed set of attestation points with +variable payout curves (e.g., just modifying some set of the CTV points). +Defer to you on performance, but this could help enable some more HFT-y +experiences for DLCs in LN + +Best, + +Jeremy +-- +@JeremyRubin <https://twitter.com/JeremyRubin> +<https://twitter.com/JeremyRubin> + + +On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> Hi dlc-dev and bitcoin-dev, +> +> tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*. +> +> +> + +--000000000000d7727705d6a7a99f +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= +t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Lloyd,</= +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:#000= +000">This is an excellent write up, the idea and benefits are clear.</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" styl= +e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">= +Is it correct that in the case of a 3/5th threshold it is a total 10x * 30x= + =3D 300x improvement? Quite impressive.</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">I have a few notes of possib= +le added benefits / features of DLCs with CTV:</div><div class=3D"gmail_def= +ault" 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">1) CTV also enables a = +"trustless timeout" branch, whereby you can have a failover claim= + that returns funds to both sides.</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">There are a few ways to do this:<= +/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:#00= +0000">A) The simplest is just an oracle-free <STH(timeout tx)> CTV wh= +ereby the timeout=C2=A0transaction=C2=A0has an absolute/relative timelock a= +fter the creation of the DLC in question.</div><div class=3D"gmail_default"= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000= +000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helv= +etica,sans-serif;font-size:small;color:#000000">B) An alternative approach = +I like is to have the base DLC have a branch `<STH(begin timeout)> CT= +V` which pays into a DLC that is the exact same except it removes the just-= +used branch and replaces it with `<STH(timeout tx)> CTV` which contai= +ns a relative timelock R for the desired amount of time to resolve. This ha= +s the advantage of always guaranteeing at least R amount of time since the = +Oracles have been claimed to be non-live to "return funds" =C2=A0= +to parties participating</div><div class=3D"gmail_default" style=3D"font-fa= +mily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></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">2= +) CTV DLCs are non-interactive asynchronously third-party unilaterally crea= +table.</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti= +ca,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;co= +lor:#000000">What I mean by this is that it is possible for a single party = +to create a DLC on behalf of another user since there is no required per-in= +stance pre-signing or randomly generated state. E.g., if Alice wants to cre= +ate a DLC with Bob, and knows the contract details, oracles, and a key for = +Bob, she can create the contract and pay to it unilaterally as a payment to= + Bob.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic= +a,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_d= +efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col= +or:#000000">This enables use cases like pay-to-DLC addresses. Pay-to-DLC ad= +dresses can also be constructed and then sent (along with a specific amount= +) to a third party service (such as an exchange or Lightning node) to creat= +e DLCs without requiring the third party service to do anything other than = +make the payment as requested.</div><div class=3D"gmail_default" style=3D"f= +ont-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_default"= + style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000= +000">3) CTV DLCs can be composed in interesting ways</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">Options over DLC= +s open up many exciting types of instrument where Alice can do things like:= +</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san= +s-serif;font-size:small;color:#000000">A) Create a Option expiring in 1 wee= +k where Bob can add funds to pay a premium and "Open" a DLC on an= + outcome closing in 1 year</div><div class=3D"gmail_default" style=3D"font-= +family:arial,helvetica,sans-serif;font-size:small;color:#000000">B) Create = +an Option expiring in 1 week where one-of-many Bobs can pay the premium (on= +-chain DEX?).</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:s= +mall;color:#000000"><span class=3D"gmail-Apple-converted-space">=C2=A0</spa= +n>See=C2=A0<a href=3D"https://rubin.io/bitcoin/2021/12/20/advent-23/">https= +://rubin.io/bitcoin/2021/12/20/advent-23/</a> for more concrete stuff aroun= +d this.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"g= +mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma= +ll;color:#000000">There are also opportunities for perpetual-like contracts= + where you could combine into one logical DLC 12 DLCs closing 1 per month t= +hat can either be payed out all at once at the end of the year, or profit p= +ulled out partially at any time earlier.</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">4) This satisfies (I think?)= + my request to make DLCs expressible as Sapio contracts in <a href=3D"https= +://rubin.io/bitcoin/2021/12/20/advent-23/">https://rubin.io/bitcoin/2021/12= +/20/advent-23/</a></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">5) An additional performance improvement can be ha= +d for iterative DLCs in Lightning where you might trade over a fixed set of= + attestation points with variable payout curves (e.g., just modifying some = +set of the CTV points). Defer to you on performance, but this could help en= +able some more HFT-y experiences for DLCs in LN</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">Best,</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">Jeremy</d= +iv><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_= +signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubi= +n" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyR= +ubin" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D"g= +mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 24, 2022 at 3= +:04 AM Lloyd Fournier via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lis= +ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote= +:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= +8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204= +,204,204);padding-left:1ex"><div dir=3D"ltr"><pre>Hi dlc-dev and bitcoin-de= +v, + +tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a = +lot*. +</pre></div><br> +</blockquote></div></div> + +--000000000000d7727705d6a7a99f-- + |