path: root/b0/a37a2caaa79a11a622bc6fc632fb869c5dd48e

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F1F22C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 07:18:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CCE2B401EE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 07:18:41 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level: 
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, 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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VOf8CjE7fP5m
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 07:18:40 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 309D5401EC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Feb 2022 07:18:40 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id k13so20923542lfg.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 05 Feb 2022 23:18:40 -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=IEB81x5Tz5jUfmG5h9Hobxb0pRdcBFp/vlp6+oG4+xw=;
 b=hScQgd4xUirhOlZI7GgvLfzwf7NK5PPiN2nkeMU5rndO0E+bZrhK52C6FVTPH1Tfe+
 z+006N3Cn28+352Bli4sq/sH6FJrgROvpKxyT9dJsgLV8FesAsB1k0sgRqLYhbsf8ohG
 m5U9ylDAA26wPCcjQhtr2/ngALVB1eXIP8MYKAZl1IWLj0JDE15T5XMz+nSaY5pDvjpK
 7w2hOuqXogiVBb9OURgPLCqc7GQgd6FyXUYWmsGKVDZoLWFEV6Bo60AwsAQ/oudT7O0Z
 P6dY9VBLjRAmQa0shfs0z+xRYgqh5GkVD4l9moRiiMx95914nEnQfrOliOa3LTSrQdVG
 isiw==
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=IEB81x5Tz5jUfmG5h9Hobxb0pRdcBFp/vlp6+oG4+xw=;
 b=nt8aXveMYU6DXXQjBmXabozFthh9qdhbbnuxOWz4nIDEFq0ApT0a2a11jSAaktvb3j
 E7eSq+Hu6rHUN+8pLnJbexKgudUPGyjjDEAXY4kSeC98ynzcWx5gMBrss+EgaKuujzwi
 V+x1dp52VhSvmA5c84Wu/oTHzshMIezVx1D25Y7Z6aWAOcjLpgFUu/zfTLxJ70wucmur
 SsEJsfqr5EBfTlL0ECyFR5eQ+vkmsE5dFYvzk92yZur85N4eCIKW+Myd3GnxHwYyyHns
 ufd2oxG/RFeSe6cH/tm3gEinVGjQdBdrGfd8napPBhM1C6ck8SxGRjVigYNeZO6maMSY
 Om7A==
X-Gm-Message-State: AOAM533wMUuFm2BfUYOEecV24qqBB7V8epU7npwfeisejNEYAb1UOVO/
 6F/ecwJ5IJO7MDZ9yXMxTuithEWQyn/afTWalP7cSNpFDtI=
X-Google-Smtp-Source: ABdhPJyOvYUmhxNZXVdpSPft8YqSTwg/BiqNKrX158BPmSZmCYQUYIp1hYUKSY7Joe0cc6W3SKjWYmCvN3RWDQUK9VU=
X-Received: by 2002:a19:760d:: with SMTP id c13mr4515720lff.142.1644131917876; 
 Sat, 05 Feb 2022 23:18:37 -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: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Sun, 6 Feb 2022 18:18:11 +1100
Message-ID: <CAH5Bsr1d0_xaVW59i+pzKtU2yb1FFMG7CJZgTueJwEO7XmkdYw@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000edd22c05d7544a4e"
X-Mailman-Approved-At: Sun, 06 Feb 2022 09:28:33 +0000
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: Sun, 06 Feb 2022 07:18:42 -0000

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

Hi Jeremy,


On Sat, 29 Jan 2022 at 04:21, 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.
>

Yes I think so but I am mostly guessing these numbers. The improvement is
several orders of magnitude. Enough to make almost any payout curve
possible without UX degredation I think.


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

This is an interesting point -- I hadn't thought about interactivity prior
to this.

I agree CTV makes possible an on-chain DEX kind of thing where you put in
orders by sending txs to a DLC address generated from a maker's public key.
You could cancel the order by spending out of it via some cancel path. You
need to inform the maker of (i) your public key  (maybe you can use the
same public key as one of the inputs) and (ii) the amount the maker is
meant to put in (use fixed denominations?).

Although that's cool I'm not really a big fan of "putting the order book
on-chain" ideas because it brings up some of the problems that EVM DEXs
have.
I like centralized non-custodial order books.
For this I don't think that CTV makes a qualitative improvement given we
can use ANYONECANPAY to get some non-interactivity.
For example here's an alternative design:

The *taker*  provides a HTTP REST api where you (a maker) can:

1. POST an order using SIGHASH_ANYONECANPAY signed inputs and contract
details needed to generate the single output (the CTV DLC). The maker can
take the signatures and complete the transaction (they need to provide an
exact input amount of course).
2. DELETE an order -- the maker does some sort of revocation on the DLC
output e.g. signs something giving away all the coins in one of the
branches. If a malicious taker refuses to delete you just double spend one
of your inputs.

If the taker wants to take a non-deleted order they *could* just finish the
transaction but if they still have a connection open with the maker then
they could re-contact them to do a normal tx signing (rather than useing
the ANYONECANPAY signatures).
The obvious advantage here is that there are no transactions on-chain
unless the order is taken.
Additionally, the maker can send the same order to multiple takers -- the
takers will cancel each other's transactions should they broadcast the
transactions.
Looking forward to see if you can come up with something better than this
with CTV.
The above is suboptimal as getting both sides to have a change output is
hard but I think it's also difficult in your suggestion.
It might be better to use SIGHASH_SINGLE + ANYONECANPAY so the maker has to
be the one to provide the right input amount but the taker can choose their
change output and the fee...


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

I'm not sure what is meant concretely by (5) but I think overall
performance is ok here. You will always have 10mins or so to confirm the
DLC so you can't be too fussy about performance!

LL

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

<div dir=3D"ltr"><div dir=3D"ltr">Hi Jeremy,<br><div><br></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, 29 J=
an 2022 at 04:21, Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu" target=3D"_=
blank">jlrubin@mit.edu</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Lloyd,<=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:rgb(0,0,0)">This is an excellent write up, the i=
dea and benefits are clear.</div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Is it co=
rrect that in the case of a 3/5th threshold it is a total 10x * 30x =3D 300=
x improvement? Quite impressive.</div></div></div></blockquote><div><br></d=
iv><div>Yes I think so but I am mostly guessing these numbers. The improvem=
ent is several orders of magnitude. Enough to make almost any payout curve =
possible without UX degredation I think.</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)"><br></div><div 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 with CTV:</div><div style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div 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 can have a=
 failover claim that returns funds to both sides.</div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">There are a few ways to do this:</div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">A) The simplest is just an oracle-free &lt;STH(timeout tx)&gt; C=
TV whereby the timeout=C2=A0transaction=C2=A0has an absolute/relative timel=
ock after the creation of the DLC in question.</div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(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 is the =
exact same except it removes the just-used branch and replaces it with `&lt=
;STH(timeout tx)&gt; CTV` which contains a relative timelock R for the desi=
red amount of time to resolve. This has the advantage of always guaranteein=
g at least R amount of time since the Oracles have been claimed to be non-l=
ive to &quot;return funds&quot; =C2=A0to parties participating</div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">2) CTV DLCs are non-intera=
ctive asynchronously third-party unilaterally creatable.</div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">What I mean by this is that it is possible for a singl=
e party to create a DLC on behalf of another user since there is no require=
d per-instance pre-signing or randomly generated state. E.g., if Alice want=
s 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 pa=
yment to Bob.</div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,he=
lvetica,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 an=
d then sent (along with a specific amount) to a third party service (such a=
s an exchange or Lightning node) to create DLCs without requiring the third=
 party service to do anything other than make the payment as requested.</di=
v></div></div></blockquote><div><br></div><div>This is an interesting point=
 -- I hadn&#39;t thought about interactivity prior to this.=C2=A0</div><div=
><br></div><div>I agree CTV makes possible an on-chain DEX kind of thing wh=
ere you put in orders by sending txs to a DLC address generated from a make=
r&#39;s public key. You could cancel the order by spending out of it via so=
me cancel path. You need to inform the maker of (i) your public key=C2=A0 (=
maybe you can use the same public key as one of the inputs) and (ii) the am=
ount the maker is meant to put in (use fixed denominations?).</div><div><br=
></div><div>Although that&#39;s cool I&#39;m not really a big fan of &quot;=
putting the order book on-chain&quot; ideas because it brings up some of th=
e problems that EVM DEXs have.</div><div>I like centralized non-custodial o=
rder books.</div><div>For this I don&#39;t think that CTV makes a qualitati=
ve=C2=A0improvement given we can use ANYONECANPAY to get some non-interacti=
vity.</div><div>For example here&#39;s an alternative=C2=A0design:</div><di=
v><br></div><div>The *taker*=C2=A0 provides a HTTP REST api where you (a ma=
ker) can:</div><div><br></div><div>1. POST an order using SIGHASH_ANYONECAN=
PAY signed inputs and contract details needed to generate the single output=
 (the CTV DLC). The maker can take the signatures and complete the transact=
ion (they need to provide an exact input amount of course).</div><div>2. DE=
LETE an order -- the maker does some sort of revocation on the DLC output e=
.g. signs something giving away all the coins in one of the branches. If a =
malicious taker refuses to delete you just double spend one of your inputs.=
</div><div><br></div><div>If the taker wants to take a non-deleted=C2=A0ord=
er they *could* just finish the transaction but if they still have a connec=
tion open with the maker then they could re-contact them to do a normal tx =
signing (rather than useing the ANYONECANPAY signatures).</div><div>The obv=
ious advantage here is that there are no transactions on-chain unless the o=
rder is taken.</div><div>Additionally, the maker can send the same order to=
 multiple takers -- the takers will cancel each other&#39;s transactions sh=
ould they broadcast the transactions.</div><div>Looking forward to see if y=
ou can come up with something better than this with=C2=A0CTV.=C2=A0</div><d=
iv>The above is suboptimal as getting both sides to have a change output is=
 hard but I think it&#39;s also difficult in your suggestion.</div><div>It =
might be better to use SIGHASH_SINGLE=C2=A0+ ANYONECANPAY so the maker has =
to be the one to provide the right input amount but the taker can choose th=
eir change output and the fee...</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)">3) CTV DLCs can be composed in i=
nteresting ways</div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Options over DLCs op=
en up many exciting types of instrument where Alice can do things like:</di=
v><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r: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 DLC on an outcome closing in 1 yea=
r</div><div 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 style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div =
style=3D"font-family:arial,helvetica,sans-serif;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/ad=
vent-23/</a> for more concrete stuff around this.<br></div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">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 style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div st=
yle=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 Sa=
pio 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 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)"><br></div><div 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 fix=
ed set of attestation points with variable payout curves (e.g., just modify=
ing some set of the CTV points). Defer to you on performance, but this coul=
d help enable some more HFT-y experiences for DLCs in LN</div></div></div><=
/blockquote><div><br></div><div>I&#39;m not sure what is meant concretely b=
y (5) but I think overall performance is ok here. You will always have 10mi=
ns or so to confirm the DLC so you can&#39;t be too fussy about performance=
!</div><div><br></div><div>LL</div></div></div>

--000000000000edd22c05d7544a4e--