path: root/59/3fb5fd83f1e92f36b72ebd4a30e1135f928aae

Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6EDCBC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 19:38:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 51F58405B4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 19:38:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.269
X-Spam-Level: *
X-Spam-Status: No, score=1.269 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, FORGED_GMAIL_RCVD=1,
 FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.346,
 MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XD8XFb8XMAHM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 19:38:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [IPv6:2a00:1450:4864:20::12d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 5A13440106
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 19:38:43 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id o12so13742799lfg.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 11:38:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:cc;
 bh=foTdXSDuouUcImAUB50DpaB/7X1aFIHGtpNB6OI+FTc=;
 b=K63/IbF3fuKlTrB0b3M+VVN4oq5SWrWr5GaXVRUP0hNNqMXSku+pVUN7Y6D7l+N+xo
 tcEI1AqTe7pD/V/Hno4mmq8qHWGCGg21ZEFDpTTFRqN7Gk1auIhrNcH8LPvnbK51jscJ
 HzvDkFiGm6sDcVw4pMqaMXSLAy7EcT5wCQLpeZfeA8FKLCSHXU6zaP7JebwO3ua/ZQ3q
 j6fKbFti+R1O0xeTK3NllmfWcl5hLAS8oWevLuf0ueqJyG8gMVY+mgjRtF0ZryTKn7iw
 SRgN8/s9e4nmBu0NbdBCUgzsQ3YKmuOFeF3oLM47Ds81Mn3TMNElz+sJsMgiBjCXxWUi
 pNpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:cc;
 bh=foTdXSDuouUcImAUB50DpaB/7X1aFIHGtpNB6OI+FTc=;
 b=CX/b5kJD/tOsaFGvZBz8UUNvIvC5WNrX4AYUNhiweh6ev3H68Bjh8lmpe54/3ARR/Q
 COalNO3/W7HTl4yGj2lIuEvfDvHZZuZr37TM35QfNoIT+pG0iomqsgM2B3KXjnZWCjmp
 JAfO4ViVmU5/aUFF4mFCh9af6OW2/o53qGbOepK9tmYqrfXKYiu7zAOQcpsm7Iy25OIa
 8Tqke5dIzzReVXWys/4YoEhG0YCplNipHP6lO5ZS6PGc3VtmVhUC3JcKTsc5scRLc/JD
 ScC2LSoT/KlR5Uv1CphDzzxSVzbmO0BjvcSVUmmRoG1fxcfAK2kBTgB4S6yp9ONulnXV
 7l5A==
X-Gm-Message-State: AOAM532uEW0aqR3OEadbOogQ5FdhYJW/HnYXCpwsgVGhc+qU+u8C2x4O
 xDdQQT214w47mmXxPr0HH3jBt4wOcfwWnujEf9m9KTs2
X-Received: by 2002:ac2:5fc7:: with SMTP id q7mt3148962lfg.175.1643398720707; 
 Fri, 28 Jan 2022 11:38:40 -0800 (PST)
MIME-Version: 1.0
References: <CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com>
 <CAD5xwhiJiopwH87Bn+yq_0-XXSJYOtNzUg4JCaYwuj=oo9CacA@mail.gmail.com>
In-Reply-To: <CAD5xwhiJiopwH87Bn+yq_0-XXSJYOtNzUg4JCaYwuj=oo9CacA@mail.gmail.com>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Fri, 28 Jan 2022 11:38:29 -0800
Message-ID: <CAD5xwhgFUz8F4h0J1kXUazXvhJvTuzKTtXkKqHU7T5QoLe11-A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fa8e5a05d6a994d7"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 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 19:38:45 -0000

--000000000000fa8e5a05d6a994d7
Content-Type: text/plain; charset="UTF-8"

Apologies for the double post*, but I just had a follow up idea
that's pretty interesting to me.

You can make the close portion of a DLC be an "optimistic" execution with a
choice of justice scheme. This enables closing a DLC somewhat securely
without exposing the oracles on-chain at all.

Assuming honest oracles, the only cost of this mechanism over previous is
that you have to do a script path spend (but it can be a top-level branch,
since it's the "most likely" one).


For every DLC branch like:

*<CET-hash-i> CHECKTEMPLATEVERIFY
<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*


add a 2 branches:


*<CET-hash-A> CHECKTEMPLATEVERIFY
<Alice> CHECKSIG
*

*<CET-hash-B> CHECKTEMPLATEVERIFY
<Bob> CHECKSIG*


This enables Alice or Bob to "lock in" a redemption of the contract
that becomes spendable by them after <period>. CET-hash-* should
include a nLockTime/nSequence such that it is at the same time as the
attestation points should be known.


Where CET-hash-T sends funds to a DLC that has the following conditions:


(cooperate):

*pk_internal=musig(Alice, Bob)*

or (unilateral timeout)

*<T> Checksig <2 weeks> CSV*

or (show oracles for this outcome)

*<CET-hash-i> CHECKTEMPLATEVERIFY*

*<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*

or (justice with no punishment), forall j !=i:

*<CET-hash-j> CHECKTEMPLATEVERIFY*

*<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*

or (justice with punishment), forall j!=i:

*<CET-hash-punish-j, send funds to not-T> CHECKTEMPLATEVERIFY*

*<attestation-point1> CHECKSIG
<attestation-point2> CHECKSIGADD
<attestation-point3> CHECKSIGADD
2 EQUAL*


Justice with punishment seems to me to be the better option since T is
actively choosing this resolution (the CTV transition is signed), but
justice with no punishment might be better if you think the oracles
might screw you over and collude to steal.

One interesting question is if the justice transactions can be
"compressed" to be fewer for a given outcome. I.e., if Bob has claimed
that the outcome is 35, and there are 100 total outcomes, do we need
99 justice paths or is there a way to make fewer of them? Intuitively,
it would seem so, because if we have a 8-10 threshold for picking a
path, a 3-10 proof would be sufficient to prove Bob claimed to know
the 8-10 falsely. However, that then means 3-10 could collude, v.s.
the fraud proof requiring a full 8-10 counter. Things to think about!


Best,


Jeremy


* this might actually be a triple or quadruple post depending on how
you count, I adjusted which email was the subscriber on my mailing
list account and resultantly sent from the old address... sincere
apologies if you are seeing this message >1 times to those who were on
the CC.

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


On Fri, Jan 28, 2022 at 9:21 AM Jeremy <jlrubin@mit.edu> wrote:

> 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>
>
>
> 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*.
>>
>>
>>

--000000000000fa8e5a05d6a994d7
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"><div class=3D"gmail_defau=
lt">Apologies for the double post*, but I just had a follow up idea that&#3=
9;s=C2=A0pretty interesting to me.</div><div class=3D"gmail_default"><br></=
div><div class=3D"gmail_default">You can make the close portion of a DLC be=
 an &quot;optimistic&quot; execution with a choice of justice scheme. This =
enables closing a DLC somewhat securely without exposing the oracles on-cha=
in at all.</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_=
default">Assuming=C2=A0honest oracles, the only cost of this mechanism over=
 previous is that you have to do a script path spend (but it can be a top-l=
evel branch, since it&#39;s the &quot;most likely&quot; one).</div><div cla=
ss=3D"gmail_default"><br></div><div class=3D"gmail_default"><br></div><div =
class=3D"gmail_default">For every DLC branch like:</div><div class=3D"gmail=
_default"><br></div><div class=3D"gmail_default" style=3D"font-family:Arial=
,Helvetica,sans-serif"><pre style=3D"white-space:pre-wrap;font-family:arial=
,helvetica,sans-serif;color:rgb(34,34,34)"><b>&lt;CET-hash-i&gt; CHECKTEMPL=
ATEVERIFY
&lt;attestation-point1&gt; CHECKSIG
&lt;attestation-point2&gt; CHECKSIGADD
&lt;attestation-point3&gt; CHECKSIGADD
2 EQUAL</b></pre><pre style=3D"white-space:pre-wrap;font-family:arial,helve=
tica,sans-serif;color:rgb(34,34,34)"><br></pre><pre style=3D"white-space:pr=
e-wrap;font-family:arial,helvetica,sans-serif;color:rgb(34,34,34)">add a 2 =
branches:</pre><pre style=3D"white-space:pre-wrap;font-family:arial,helveti=
ca,sans-serif;color:rgb(34,34,34)"><br></pre><pre style=3D"white-space:pre-=
wrap;color:rgb(34,34,34)"><pre style=3D"white-space:pre-wrap;font-family:ar=
ial,helvetica,sans-serif"><b>&lt;CET-hash-A&gt; CHECKTEMPLATEVERIFY
&lt;Alice&gt; CHECKSIG
</b></pre><pre style=3D"white-space:pre-wrap;font-family:arial,helvetica,sa=
ns-serif"><b>&lt;CET-hash-B&gt; CHECKTEMPLATEVERIFY
&lt;Bob&gt; CHECKSIG</b>
</pre><pre style=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-s=
erif"><b><br></b></pre><pre style=3D"white-space:pre-wrap;font-family:arial=
,helvetica,sans-serif">This enables Alice or Bob to &quot;lock in&quot; a r=
edemption of the contract that becomes spendable by them after &lt;period&g=
t;. CET-hash-* should include a nLockTime/nSequence such that it is at the =
same time as the attestation points should be known.</pre><pre style=3D"whi=
te-space:pre-wrap;font-family:arial,helvetica,sans-serif"><br></pre><pre st=
yle=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-serif">Where C=
ET-hash-T sends funds to a DLC that has the following conditions:</pre><pre=
 style=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-serif"><br>=
</pre><pre style=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-s=
erif">(cooperate):</pre><pre style=3D"white-space:pre-wrap;font-family:aria=
l,helvetica,sans-serif"><b>pk_internal=3Dmusig(Alice, Bob)</b></pre><pre st=
yle=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-serif">or (uni=
lateral timeout)</pre><pre style=3D"white-space:pre-wrap;font-family:arial,=
helvetica,sans-serif"><b>&lt;T&gt; Checksig &lt;2 weeks&gt; CSV</b></pre><p=
re style=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-serif">or=
 (show oracles for this outcome)</pre><pre style=3D"white-space:pre-wrap;fo=
nt-family:arial,helvetica,sans-serif"><b>&lt;CET-hash-i&gt; CHECKTEMPLATEVE=
RIFY</b></pre><span style=3D"color:rgb(80,0,80)"><pre style=3D"white-space:=
pre-wrap;font-family:arial,helvetica,sans-serif"><b>&lt;attestation-point1&=
gt; CHECKSIG
&lt;attestation-point2&gt; CHECKSIGADD
&lt;attestation-point3&gt; CHECKSIGADD
2 EQUAL</b></pre></span><pre style=3D"white-space:pre-wrap;font-family:aria=
l,helvetica,sans-serif">or (justice with no punishment), forall j !=3Di:</p=
re><pre style=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-seri=
f"><pre style=3D"white-space:pre-wrap"><span style=3D"font-family:arial,hel=
vetica,sans-serif"><b>&lt;CET-hash-j&gt; CHECKTEMPLATEVERIFY</b></span></pr=
e><span style=3D"color:rgb(80,0,80)"><pre style=3D"white-space:pre-wrap"><b=
>&lt;attestation-point1&gt; CHECKSIG
&lt;attestation-point2&gt; CHECKSIGADD
&lt;attestation-point3&gt; CHECKSIGADD
2 EQUAL</b></pre></span></pre><pre style=3D"white-space:pre-wrap;font-famil=
y:arial,helvetica,sans-serif">or (justice with punishment), forall j!=3Di:<=
/pre><pre style=3D"white-space:pre-wrap"><pre style=3D"white-space:pre-wrap=
;font-family:arial,helvetica,sans-serif"><b>&lt;CET-hash-punish-j, send fun=
ds to not-T&gt; CHECKTEMPLATEVERIFY</b></pre><span style=3D"color:rgb(80,0,=
80)"><pre style=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-se=
rif"><b>&lt;attestation-point1&gt; CHECKSIG
&lt;attestation-point2&gt; CHECKSIGADD
&lt;attestation-point3&gt; CHECKSIGADD
2 EQUAL</b></pre><pre style=3D"white-space:pre-wrap;font-family:arial,helve=
tica,sans-serif"><br></pre></span><pre style=3D"white-space:pre-wrap;font-f=
amily:arial,helvetica,sans-serif">Justice with punishment seems to me to be=
 the better option since T is actively choosing this resolution (the CTV tr=
ansition is signed), but justice with no punishment might be better if you =
think the oracles might screw you over and collude to steal.</pre><pre styl=
e=3D"white-space:pre-wrap;font-family:arial,helvetica,sans-serif">One inter=
esting question is if the justice transactions can be &quot;compressed&quot=
; to be fewer for a given outcome. I.e., if Bob has claimed that the outcom=
e is 35, and there are 100 total outcomes, do we need 99 justice paths or i=
s there a way to make fewer of them? Intuitively, it would seem so, because=
 if we have a 8-10 threshold for picking a path, a 3-10 proof would be suff=
icient to prove Bob claimed to know the 8-10 falsely. However, that then me=
ans 3-10 could collude, v.s. the fraud proof requiring a full 8-10 counter.=
 Things to think about!</pre><pre style=3D"white-space:pre-wrap;font-family=
:arial,helvetica,sans-serif"><br></pre><pre style=3D"white-space:pre-wrap">=
Best,</pre><pre style=3D"white-space:pre-wrap"><span style=3D"font-family:A=
rial,Helvetica,sans-serif"><br></span></pre><pre style=3D"white-space:pre-w=
rap"><span style=3D"font-family:Arial,Helvetica,sans-serif">Jeremy</span></=
pre><pre style=3D"white-space:pre-wrap"><span style=3D"font-family:Arial,He=
lvetica,sans-serif"><br></span></pre><pre style=3D"white-space:pre-wrap"><s=
pan style=3D"font-family:Arial,Helvetica,sans-serif">* this might actually =
be a triple or quadruple post depending on how you count, I adjusted which =
email was the subscriber on my mailing list account and resultantly sent fr=
om the old address... sincere apologies if you are seeing this message &gt;=
1 times to those who were on the CC.</span></pre></pre></pre></div></div><d=
iv><div dir=3D"ltr" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<=
br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRub=
in</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></d=
iv></div></div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Fri, Jan 28, 2022 at 9:21 AM Jeremy &lt;<a href=3D"mailto:j=
lrubin@mit.edu" target=3D"_blank">jlrubin@mit.edu</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">Lloyd,</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">This is an excellent write up, the idea and b=
enefits are clear.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">Is it correct that in the case of a 3/5th th=
reshold it is a total 10x * 30x =3D 300x improvement? Quite impressive.</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)">I have a few notes of possible added benefits / features of DLCs w=
ith CTV:</div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">1) CTV also enables a &quot;trustless timeout&quot; br=
anch, whereby you can have a failover claim that returns funds to both side=
s.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)">There are a few ways to do this:</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">A) The simplest=
 is just an oracle-free &lt;STH(timeout tx)&gt; CTV whereby the timeout=C2=
=A0transaction=C2=A0has an absolute/relative timelock after the creation of=
 the DLC in question.</div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)">B) An alternative approach I like is to h=
ave the base DLC have a branch `&lt;STH(begin timeout)&gt; CTV` which pays =
into a DLC that is the exact same except it removes the just-used branch an=
d replaces it with `&lt;STH(timeout tx)&gt; CTV` which contains a relative =
timelock R for the desired amount of time to resolve. This has the advantag=
e of always guaranteeing at least R amount of time since the Oracles have b=
een claimed to be non-live to &quot;return funds&quot; =C2=A0to parties par=
ticipating</div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) CTV=
 DLCs are non-interactive asynchronously third-party unilaterally creatable=
.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">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-i=
nstance pre-signing or randomly generated state. E.g., if Alice wants to cr=
eate 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 t=
o Bob.</div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)">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) t=
o create DLCs without requiring the third party service to do anything othe=
r than make the payment as requested.</div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">3) CTV DLCs can be composed in interesting ways</div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)">Options over DLCs open up many exciting types of instrument where Ali=
ce can do things like:</div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">A) Create a=
 Option expiring in 1 week where Bob can add funds to pay a premium and &qu=
ot;Open&quot; a DLC on an outcome closing in 1 year</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">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:rgb(=
0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span>=C2=A0</span>Se=
e=C2=A0<a href=3D"https://rubin.io/bitcoin/2021/12/20/advent-23/" target=3D=
"_blank">https://rubin.io/bitcoin/2021/12/20/advent-23/</a> for more concre=
te stuff around this.<br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">There are also opportunities for perp=
etual-like contracts where you could combine into one logical DLC 12 DLCs c=
losing 1 per month that can either be payed out all at once at the end of t=
he year, or profit pulled out partially at any time earlier.</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">4)=
 This satisfies (I think?) my request to make DLCs expressible as Sapio con=
tracts in <a href=3D"https://rubin.io/bitcoin/2021/12/20/advent-23/" target=
=3D"_blank">https://rubin.io/bitcoin/2021/12/20/advent-23/</a></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">5) An additional performance improvement can be had for iterative DLCs in=
 Lightning where you might trade over a fixed set of attestation points wit=
h 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 ex=
periences for DLCs in LN</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">Best,</div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Jeremy</div><br clea=
r=3D"all"><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/Jer=
emyRubin" target=3D"_blank">@JeremyRubin</a><br></div></div></div><br></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mo=
n, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.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-dev,

tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a =
lot*.
</pre></div><br>
</blockquote></div></div>
</blockquote></div></div>

--000000000000fa8e5a05d6a994d7--