path: root/d0/b3c64e4a3eb1cab5e67d9396fe0ccd3b62996d

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 =
&quot;trustless timeout&quot; 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 &lt;STH(timeout tx)&gt; 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 `&lt;STH(begin timeout)&gt; CT=
V` which pays into a DLC that is the exact same except it removes the just-=
used branch and replaces it with `&lt;STH(timeout tx)&gt; 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 &quot;return funds&quot; =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 &quot;Open&quot; 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 &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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--