path: root/43/6501603d3ba8ee2fe9a4b1ab7a786921a0decb

Return-Path: <alex.schoof@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 395C8C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 21:14:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 19FD74014C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 21:14:29 +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: 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 ri2Xku63VIar
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 21:14:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
 [IPv6:2a00:1450:4864:20::22b])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 3830240386
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 21:14:27 +0000 (UTC)
Received: by mail-lj1-x22b.google.com with SMTP id c15so10755929ljf.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 28 Jan 2022 13:14:27 -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:to
 :cc; bh=L4+4iQujSCc8aLJ9NDCBGgtDzFAIaAYui/JzUeLS8Rk=;
 b=mACrPPuhcFNbHcTiyMrEZ1Ll0AEeDWAznIjFtymXoO1h18rx35cNdzx8SJTY9//kq7
 wqXnZUd/ldRXz/HU6V5w4jNl/2Kwz8iVYc04C9t1SjIuhC+BLtxiHUPxAnzPoh565sSU
 IK5BZM1DQOgK7t53AUr0raoHJhYg5KP2hzEgBJO15bWn6uHNQgvQ5P6kCNiSTgQasYQ5
 kZicNegepmLPFXZs5bk6VpG97Sg7OIMVW2AvrqMmljteQNLyAVWYuvmFFYcuYV2mqVDY
 uO6xWXOu2W8O5iL5Ez19GNx5BAzO46OwRxI/R2tbUAY9kATnKDSGb7JdBwqz+SnEB99a
 8+UQ==
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:to:cc;
 bh=L4+4iQujSCc8aLJ9NDCBGgtDzFAIaAYui/JzUeLS8Rk=;
 b=1hTFuaXgJZavL0ymAA/R+QM9XJN9fhe0/sgiaW1MWUQ2+QCefUvHMAeXn8EiZtHfEI
 9mDiDMwWkvKGJWnxFTbVhA32AZJrRk1VP/l7Ef5oIcIrz0y/DdglOGx0wJ3QkGJCUzcB
 7liNFRHw5Ki3fSm5+Nt0KtAgrs3e2Ezynq3S6WihIZwRmdbpVV12t+BUDevDcj4O/azY
 cpxCjMhD2Td2bvTFG9Rvmw4cxwgpxUftAmxlPjVRTwKZz1NBCA7yVIZLtRUkdnE0KhVN
 LUwuvW6tZT6S3kpKE0cRfrVVtNGVPs+2Mn1aI6jcKIHBmT6LcoBeR8pVJKqSZGXjrq3X
 B4Dg==
X-Gm-Message-State: AOAM532qVLhw+kfIu0YhGmtnPYw1+Kd5YY4TklLtG+2BkLIVH2LAUw+q
 5YN8wpesh0v3SZSAb62gGwEDCtg+rAl6o9E3GvE=
X-Google-Smtp-Source: ABdhPJzpR1tllNCYpdOmKJWI9IBIK/2NCZMbxHNlHps1VweLKz6tsT7jrD17PQV8U24wMm7WDt0R4APpuGtb2aiG0U0=
X-Received: by 2002:a2e:9055:: with SMTP id n21mr6961654ljg.263.1643404465018; 
 Fri, 28 Jan 2022 13:14:25 -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: Alex Schoof <alex.schoof@gmail.com>
Date: Fri, 28 Jan 2022 16:14:12 -0500
Message-ID: <CA+2b5C144Hz299qLiJ4beSw_x5U9xUbEXgG+rpbqJng2zCfhKQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005c21ec05d6aaeb9e"
X-Mailman-Approved-At: Sat, 29 Jan 2022 00:20:54 +0000
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 21:14:29 -0000

--0000000000005c21ec05d6aaeb9e
Content-Type: text/plain; charset="UTF-8"

> CTV DLCs are non-interactive asynchronously third-party unilaterally
creatable.

This is super interesting. I think that would make it easier to do
multi-party DLCs. With a "normal" DLC, you need to have N parties
exchanging and signing CETs and you end up with a combinatorial explosion
of signing operations to perform. It sounds like if you did it with CTV,
then each party could compute all the outcomes on their own in parallel (to
be able to generate commitments for each tapleaf) and then just exchange
and sign the single opening transaction for the DLC. Or for devices with
limited resources, you could have a coordinator compute the whole TR tree
and publish a ZKP to the other signers.

Cheers,

Alex


On Fri, Jan 28, 2022 at 12:21 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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>
> <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*.
>>
>>
>> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 


Alex Schoof

--0000000000005c21ec05d6aaeb9e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"color:rgb(0,0,0);font-family:aria=
l,helvetica,sans-serif">CTV DLCs are non-interactive asynchronously third-p=
arty unilaterally creatable.</span><div><span style=3D"color:rgb(0,0,0);fon=
t-family:arial,helvetica,sans-serif"><br></span></div><div><font color=3D"#=
000000" face=3D"arial, helvetica, sans-serif"><span style=3D"caret-color: r=
gb(0, 0, 0);">This is super interesting. I think that would make it easier =
to do multi-party DLCs. With a &quot;normal&quot; DLC, you need to have N p=
arties exchanging and signing CETs and you end up with a combinatorial expl=
osion of signing operations to=C2=A0perform. It sounds like if you did it w=
ith CTV, then each party could compute all the outcomes on their own in par=
allel (to be able to generate commitments for each tapleaf) and then just e=
xchange and sign the single opening transaction for the DLC. Or for devices=
 with limited resources, you could have a coordinator compute the whole TR =
tree and publish a ZKP to the other signers.=C2=A0</span></font></div><div>=
<br></div><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif=
"><span style=3D"caret-color: rgb(0, 0, 0);">Cheers,</span></font></div><di=
v><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><span style=
=3D"caret-color: rgb(0, 0, 0);"><br></span></font></div><div><font color=3D=
"#000000" face=3D"arial, helvetica, sans-serif"><span style=3D"caret-color:=
 rgb(0, 0, 0);">Alex</span></font></div><div><font color=3D"#000000" face=
=3D"arial, helvetica, sans-serif"><span style=3D"caret-color: rgb(0, 0, 0);=
"><br></span></font></div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Fri, Jan 28, 2022 at 12:21 PM Jeremy via bitco=
in-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.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;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Lloyd,</=
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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">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:rgb(0,0,0)"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">Is it correct that in the case of a 3/5th threshold it is a tot=
al 10x * 30x =3D 300x improvement? Quite impressive.</div><div class=3D"gma=
il_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-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I have a f=
ew notes of possible added benefits / features of DLCs with CTV:</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-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)=
">1) CTV also enables a &quot;trustless timeout&quot; branch, whereby you c=
an 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-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The=
re are a few ways to do this:</div><div class=3D"gmail_default" style=3D"fo=
nt-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,san=
s-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 quest=
ion.</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;c=
olor:rgb(0,0,0)">B) An alternative approach I like is to have the base DLC =
have a branch `&lt;STH(begin timeout)&gt; CTV` which pays into a DLC that i=
s the exact same except it removes the just-used branch and replaces it wit=
h `&lt;STH(timeout tx)&gt; CTV` which contains a relative timelock R for th=
e desired amount of time to resolve. This has the advantage of always guara=
nteeing at least R amount of time since the Oracles have been claimed to be=
 non-live to &quot;return funds&quot; =C2=A0to parties participating</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)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) CTV DLCs are non-int=
eractive asynchronously third-party unilaterally creatable.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Wha=
t 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-signi=
ng or randomly generated state. E.g., if Alice wants to create a DLC with B=
ob, and knows the contract details, oracles, and a key for Bob, she can cre=
ate the contract and pay to it unilaterally as a payment to Bob.</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-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)=
">This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses ca=
n also be constructed and then sent (along with a specific amount) to a thi=
rd party service (such as an exchange or Lightning node) to create DLCs wit=
hout requiring the third party service to do anything other than make the p=
ayment as requested.</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)">3) CTV DLCs can be composed in interesting ways</div><div class=3D"gmai=
l_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-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Options ove=
r DLCs open up many exciting types of instrument where Alice can do things =
like:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,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 &quot;Open&quot; a D=
LC 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: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-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)"><span>=C2=A0</span>See=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 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:rgb(0,0,0)"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)">There are also opportunities for perpetual-like c=
ontracts 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.</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or: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 satisf=
ies (I think?) my request to make DLCs expressible as Sapio contracts 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 class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">5) An additi=
onal performance improvement can be had for iterative DLCs in Lightning whe=
re you might trade over a fixed set of attestation points with variable pay=
out 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</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)">Best,</div><div class=3D"gmail_default" style=3D"fon=
t-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><div><div dir=3D"ltr">=
<div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=
=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" tar=
get=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jan 24, 2022 at 3:04 AM Ll=
oyd Fournier via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><pre>Hi dlc-dev and b=
itcoin-dev,

tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a =
lot*.
</pre></div><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><br><br>Alex Schoof</div>

--0000000000005c21ec05d6aaeb9e--