CTV dramatically improves DLCs

Hi dlc-dev and bitcoin-dev,

tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a lot*.

## Introduction

Dryja introduced the idea of Discreet Log Contracts (DLC) in his breakthrough work[1]. Since then (DLC) has become an umbrella term for Bitcoin protocols that map oracle secret revelation to an on-chain transaction which apportions coins accordingly. The key property that each protocol iteration preserves is that the oracle is an *oblivious trusted party* -- they do not interact with the blockchain and it is not possible to tell which event or which oracle the two parties were betting on with blockchain data alone.

`OP_CHECKTEMPLATEVERIFY` (CTV) a.k.a. BIP119 [2] is a proposed upgrade to Bitcoin which is being actively discussed. CTV makes possible an optimized protocol which improves DLC performance so dramatically that it solves several user experience concerns and engineering difficulties. To me this is the most compelling and practical application of CTV so I thought it's about time to share it!

## Present state of DLC specification

The DLC specifications[3] use adaptor signatures to condition each possible payout. The protocol works roughly like this:

1. Oracle(s) announce events along with a nonce `R` for each event.
Let's say each event has `N` outcomes.
2. Two users who wish to make a bet take the `R` from the oracle
announcement and construct a set of attestation points `S` and their
corresponding payouts.
3. Each attestation point for each of the `N` outcomes is calculated
like `S_i = R + H(R || X || outcome_i) * X` where `X` is the oracle's
static key.
4. The users combine the attestation points into *contract execution
transaction* (CET) points e.g `CET_i = S1_i + S2_i + S3_i`.
   Here `CET_i` is the conjunction (`AND`) between the event outcomes
represented by `S1_i, S2_i, S3_i`.
5. The oracle(s) reveals the attestation `s_i` where `s_i * G = S_i`
if the `i`th is the outcome transpired.
6. Either of the parties takes the `s_i`s from each of the
attestations and combines them e.g. `cet_i = s1_i + s2_i + s3_i` and
uses `cet_i` to decrypt the CET adaptor signature encrypted by `CET_i`
and broadcast the transaction.

## Performance issues with DLCs

In the current DLC protocol both parties compute:
  - `E * N` attestation points where `E` is the number of events you
are combining and `N` is the number of outcomes per event. (1 mul)
  - `C >= E * N` CET adaptor signatures and verify them. (2 mul -- or
with MuSig2, 3 muls).

Note that the number of CETs can be much greater than the number of attestation points. For example, if an oracle decomposes the price of BTC/USD into 20 binary digits e.g. 0..(2^20 -1), you could have `E=20,N=2,C=2^20`. So the biggest concern for worst case performance is the adaptor signatures multiplications.

If we take a multiplication as roughly 50 microseconds computing MuSig2 adaptor signatures for ~6000 CETs would take around a second of cpu time (each) or so. 6000 CETs is by no means sufficient if you wanted, for example, to bet on the BTC/USD price per dollar. Note there may be various ways of precomputing multiplications and using fast linear combination algorithms and so on but I hope this provides an idea of the scale of the issue. Then consider that you may want to use a threshold of oracles which will combinatorially increase this number (e.g. 3/5 threshold would 10x this).

You also would end up sending data on the order of megabytes to each other.

## committing to each CET in a tapleaf with CHECKTEMPLATEVERIFY

What can we do with OP_CTV + Taproot to improve this?

Instead of creating an adaptor signature for every CET, commit to the CET with OP_CTV in a tapleaf:

``` <CET-hash_i> CHECKTEMPLATEVERIFY <CET_i> CHECKSIG ```

When the oracle(s) reveals their attestations either party can combine them to get the secret key corresponding to `CET_i` and spend the coins to the CET (whose CTV hash is `CET-hash`) which distributes the funds according to the contract.

This replaces all the multiplications needed for the adaptor signature with a few hashes! You will still need to compute the `CET_i` which will involve a point normalisation but it still brings the computational cost per CET down from hundreds of microseconds to around 5 (per party). There will be a bit more data on chain (and a small privacy loss) in the uncooperative case but even with tens of thousands of outcomes it's only going to roughly double the virtual size of the transaction. Keep in mind the uncooperative case should hopefully be rare too esp when we are doing this in channels.

The amount of data that the parties need to exchange is also reduced to a small constant size.

## getting rid of combinatorial complexity of oracle thresholds

Now that we're using script it's very easy to do a threshold along with the script. e.g. a 2/3:

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

The improvement here is that the amount of computation and communication does not increase with the number of oracles in the threshold. The size of the witness only increases linearly in the number of oracles and only in the un-cooperative case. This also solves a security issue with the current spec because attestation points from different oracles are no longer summed (which is a problem [4]).

## Getting rid of the attestation point multiplication

It's possible to get rid of the EC multiplications from the attestation point computation too. This is optimistically a 10x improvement but in the most important cases it's a negligible improvement since computing the `E*N` attestion points is a small fraction of the total CET point computation.

Recall the original Schnorr style DLC attestation point was computed like:

```
S_i = R + H(R || X || outcome_i) * X
```

So for each outcome we have to hash it and multiply the result by the oracle's public key. I don't think hashing is necessary[6].

First note that an oracle attestation scheme is not a signature scheme:

1. The users need to be able to compute the attestation point beforehand (signature schemes do not require the verifier to be able to compute anything before hand). 2. There is a very different concept of a forgery -- you don't care about someone being able to forge signatures under the oracle's key in general you only care about them being able to forge an attestation corresponding to some previously announced event i.e. you only care about forgeries of things that people are actually betting on.

Long story[6] short we can get rid of the hash and do the following instead for the `outcome_i`:

``` S_i = R + i * X ```

For each `outcome_i` the oracle will reveal a different linear combination of `R` and `X`. However, if we still want to preserve the ability to add attestation points together to create an AND like condition for points attestations from the same oracle so we have to do:

``` S_i = i * R + X ```

which when we combine two attestations from the same oracle becomes:

`S1_i + S2_j = (i*R1 + X) + (j*R2 + X) = i*R1 + j*R2 + 2*X`

As you can see the addition preserves the linear structure. If you were to do the original suggestion it would be:

`S1_i + S2_j = (i*X + R1 + (j*X + R2) = (i + j)*X + R1 + R2)`

Which loses the structure and creates collisions e.g. `S1_1 + S2_2 = S1_2 + S2_1` . Note that this collision problem also exists in the current spec and original paper[4,5] but requires a solving a hashing k-sum that should be hard to do in practice.

So, when we compute for `i in 1..N`, `S_1 = R + X` and each subsequent is `S_i = S_{i-1} + R` and so we only need to do one addition for each attestation point.

## In summary

In the worst case this improves DLC performance by ~30x compared to using MuSig2 adaptor signatures because it gets rid of all multiplications for both parties. In the case of a 3/5 threshold performance would be improved by another 10x. Depending on the kind of event, removing the attestation point multiplication will also help. Communication complexity also becomes constant.

In other words, from the user's perspective everything can happen pretty much instantly even on more resource constrained devices and bad internet connections.

The downside of the protocol is that in the un-cooperative case, the size of the witness is bigger and the transaction is distinguishable from other protocols (it's not longer scriptless).

## Credits

Special thanks to:

- Ruben Somsen who first made the observation that OP_CTV could be applied to DLCs in the way presented here. - Thibaut Le Guilly who did benchmarking on getting rid of the attestation point multiplication. - Nadav Cohen who pointed out that doing `R + i*X` was broken.

[1]: https://adiabat.github.io/dlc.pdf [2]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki [3]: https://github.com/discreetlogcontracts/dlcspecs [4]: https://bitcoinproblems.org/problems/secure-dlcs.html [5]: https://mailmanlists.org/pipermail/dlc-dev/2021-March/000065.html [6]: https://github.com/LLFourn/dlc-sec/blob/master/main.pdf

Thank you, that's an interesting application of OP_CTV.

Perhaps worth pointing out that this does not require OP_CTV but could also be enabled by other covenant constructions. For example, it seems like ANYPREVOUT-based covenants provide similar benefits. The script of the Taproot leaves could be set to

<sig> <G> CHECKSIGVERIFY <CET_i> CHECKSIGVERIFY

where <sig> is an ANYPREVOUTANYSCRIPT signature of the CET for public key P = G. When using nonce R = G, signature creation has negligible computational cost (s = 1 + H(R, P, m)). A downside compared to CTV is the additional overhead of 64 witness bytes (<sig>).

Hi,

Lloyd, thanks for this excellent writeup. I must say that indeed using CTV seems like it would very much lower the complexity of the DLC protocol (and it seems like APO would also work, thanks Jonas for pointing that out). Though thinking about it, I can't help wondering if the ideal op code for DLC wouldn't actually be CHECKSIGFROMSTACK? It feels to me that this would give the most natural way of doing things. If I'm not mistaken, this would enable simply requiring an oracle signature over the outcome, without any special trick, and without even needing the oracle to release a nonce in advance (the oracle could sign `event_outcome + event_id` to avoid signature reuse). I must say that I haven't studied covenant opcodes in detail yet so is that line of thinking correct or am I missing something?

Cheers,

Thibaut

On Wed, Jan 26, 2022 at 1:27 AM Jonas Nick via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> Thank you, that's an interesting application of OP_CTV.
>
> Perhaps worth pointing out that this does not require OP_CTV but could
> also be
> enabled by other covenant constructions. For example, it seems like
> ANYPREVOUT-based covenants provide similar benefits. The script of the
> Taproot
> leaves could be set to
>
> <sig> <G> CHECKSIGVERIFY <CET_i> CHECKSIGVERIFY
>
> where <sig> is an ANYPREVOUTANYSCRIPT signature of the CET for public key
> P = G.
> When using nonce R = G, signature creation has negligible computational
> cost (s
> = 1 + H(R, P, m)). A downside compared to CTV is the additional overhead
> of 64
> witness bytes (<sig>).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Thibaut,

CSFS might have independent benefits, but in this case CTV is not being used in the Oracle part of the DLC, it's being used in the user generated mapping of Oracle result to Transaction Outcome.

So it'd only be complimentary if you came up with something CSFS based for the Oracles.

Best,

Jeremy

On Thu, Jan 27, 2022 at 12:59 AM Thibaut Le Guilly via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> Hi,
>
> Lloyd, thanks for this excellent writeup. I must say that indeed using CTV
> seems like it would very much lower the complexity of the DLC protocol (and
> it seems like APO would also work, thanks Jonas for pointing that out).
> Though thinking about it, I can't help wondering if the ideal op code for
> DLC wouldn't actually be CHECKSIGFROMSTACK? It feels to me that this would
> give the most natural way of doing things. If I'm not mistaken, this would
> enable simply requiring an oracle signature over the outcome, without any
> special trick, and without even needing the oracle to release a nonce in
> advance (the oracle could sign `event_outcome + event_id` to avoid
> signature reuse). I must say that I haven't studied covenant opcodes in
> detail yet so is that line of thinking correct or am I missing something?
>
> Cheers,
>
> Thibaut
>

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

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.

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

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

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!

I mean that if you think of the CIT points as being the X axis (or independent axes if multivariate) of a contract, the Y axis is the dependent variable represented by the CTV hashes.

For a DLC living inside a lightning channel, which might be updated between parties e.g. every second, this means you only have to recompute the cheaper part of the DLC only if you update the payoff curves (y axis) only, and you only have to update the points whose y value changes.

For on chain DLCs this point is less relevant since the latency of block space is larger.

Hi all,

A lot is being discussed but just wanted to react on some points.

# CSFS

Lloyd, good point about CSFS not providing the same privacy benefits, and OP_CAT being required in addition. And thanks Philipp for the link to your post, it was an interesting read!

Jeremy

>CSFS might have independent benefits, but in this case CTV is not being

used in the Oracle part of the DLC, it's being used in the user generated mapping of Oracle result to Transaction Outcome.

My point was that CSFS could be used both in the oracle part but also in the transaction restriction part (as in the post by Philipp), but again it does not really provide the same model as DLC as pointed out by Lloyd.

# Performance

Regarding how much performance benefit this CTV approach would provide, without considering the benefit of not having to transmit and store a large number of adaptor signatures, and without considering any further optimization of the anticipation points computation, I tried to get a rough estimate through some benchmarking. Basically, if I'm not mistaken, using CTV we would only have to compute the oracle anticipation points, without needing any signing or verification. I've thus made a benchmark comparing the current approach with signing + verification with only computing the anticipation points, for a single oracle with 17 digits and 10000 varying payouts (between 45000 and 55000). The results are below.

Without using parallelization: baseline: [7.8658 s 8.1122 s 8.3419 s] no signing/no verification: [321.52 ms 334.18 ms 343.65 ms]

Using parallelization: baseline: [3.0030 s 3.1811 s 3.3851 s] no signing/no verification: [321.52 ms 334.18 ms 343.65 ms]

So it seems like the performance improvement is roughly 24x for the serial case and 10x for the parallel case.

The two benchmarks are available (how to run them is detailed in the README in the same folder): * https://github.com/p2pderivatives/rust-dlc/blob/ctv-bench-simulation-baseline/dlc-manager/benches/benchmarks.rs#L290 * https://github.com/p2pderivatives/rust-dlc/blob/ctv-bench-simulation/dlc-manager/benches/benchmarks.rs#L290

Let me know if you think that's a fair simulation or not. One thing I'd like to see as well is what will be the impact of having a very large taproot tree on the size of the witness data when spending script paths that are low in the tree, and how it would affect the transaction fee. I might try to experiment with that at some point.

Cheers,

Thibaut

On Mon, Feb 7, 2022 at 2:56 AM Jeremy Rubin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:

> 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!
>
>
> I mean that if you think of the CIT points as being the X axis (or
> independent axes if multivariate) of a contract, the Y axis is the
> dependent variable represented by the CTV hashes.
>
>
> For a DLC living inside a lightning channel, which might be updated
> between parties e.g. every second, this means you only have to recompute
> the cheaper part of the DLC only if you update the payoff curves (y axis)
> only, and you only have to update the points whose y value changes.
>
> For on chain DLCs this point is less relevant since the latency of block
> space is larger.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

I've created a prototype of this protocol in Sapio for your perusal:

https://github.com/sapio-lang/sapio/blob/master/sapio-contrib/src/contracts/derivatives/dlc.rs

Feel free to tweak the test and use it as a benchmark, i tested 1 oracle with 100,000 different payouts and saw it take around 13s on a release build.

I'll be playing around with this a bit (I doubt Sapio Studio can handle a gui for 100,000 nodes), but I figured it was worth a share.

Cheers,

Jeremy