CTV dramatically improves DLCs

CTV dramatically improves DLCs
2022-01-25 16:24 ` [bitcoin-dev] [dlc-dev] " Jonas Nick
                   ` (2 more replies)
  
From: Lloyd Fournier @ 2022-01-24  8:01 UTC (permalink / raw)
  To: dlc-dev, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 9139 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 9828 bytes --]

 permalink raw reply	[|nested]
2022-01-25 16:24 `  " Jonas Nick
                   ` 
  
From: Lloyd Fournier @ 2022-01-24  8:01 UTC (permalink / raw)
  To: dlc-dev, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 9139 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 9828 bytes --]

 permalink raw reply	[|nested]
2022-01-25 16:24 ` [bitcoin-dev] [dlc-dev] " Jonas Nick

  2022-01-28 16:53     ` Jeremy
  
From: Thibaut Le Guilly @ 2022-01-27  0:45 UTC (permalink / raw)
  To: Jonas Nick, Bitcoin Protocol Discussion;  dlc-dev

[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

 permalink raw reply	[|nested]
2022-01-27  0:45   ` Thibaut Le Guilly

  
From: Jeremy @ 2022-01-28 16:53 UTC (permalink / raw)
  To: Thibaut Le Guilly, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2739 bytes --]

 permalink raw reply	[|nested]
2022-01-24  8:01 [bitcoin-dev] CTV dramatically improves DLCs Lloyd Fournier
  2022-01-25 16:24 ` [bitcoin-dev] [dlc-dev] " Jonas Nick

  2022-01-28 19:38   ` Jeremy Rubin
                     ` (2 more replies)
  2022-03-15 17:28 ` Jeremy Rubin
  
From: Jeremy @ 2022-01-28 17:21 UTC (permalink / raw)
  To: Lloyd Fournier, Bitcoin Protocol Discussion;  dlc-dev

[-- Attachment #1: Type: text/plain, Size: 3343 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 8681 bytes --]

 permalink raw reply	[|nested]
2022-01-24  8:01 [bitcoin-dev] CTV dramatically improves DLCs Lloyd Fournier
  2022-01-25 16:24 ` [bitcoin-dev] [dlc-dev] " Jonas Nick

  2022-01-28 19:38   ` 
                     ` 
  2022-03-15 17:28 ` Jeremy Rubin
  
From: Jeremy @ 2022-01-28 17:21 UTC (permalink / raw)
  To: Lloyd Fournier, Bitcoin Protocol Discussion;  dlc-dev

[-- Attachment #1: Type: text/plain, Size: 3343 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 8681 bytes --]

 permalink raw reply	[|nested]
2022-01-28 17:21 ` [bitcoin-dev] " Jeremy
  2022-01-28 19:38   ` Jeremy Rubin

  2022-02-06  7:18   ` Lloyd Fournier
  
From: Alex Schoof @ 2022-01-28 21:14 UTC (permalink / raw)
  To: Jeremy, Bitcoin Protocol Discussion;  dlc-dev

[-- Attachment #1: Type: text/plain, Size: 4509 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 11221 bytes --]

 permalink raw reply	[|nested]
2022-01-28 17:21 ` [bitcoin-dev] " Jeremy
  2022-01-28 19:38   ` Jeremy Rubin
  2022-01-28 21:14   ` Alex Schoof

  2022-02-06 17:56     ` Jeremy Rubin
  
From: Lloyd Fournier @ 2022-02-06  7:18 UTC (permalink / raw)
  To: Jeremy;  Bitcoin Protocol Discussion, dlc-dev

[-- Attachment #1: Type: text/plain, Size: 5898 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 10521 bytes --]

 permalink raw reply	[|nested]
2022-02-06  7:18   ` Lloyd Fournier

  2022-02-07  2:30       ` Thibaut Le Guilly
  
From: Jeremy Rubin @ 2022-02-06 17:56 UTC (permalink / raw)
  Cc: Bitcoin Protocol Discussion, dlc-dev

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1385 bytes --]

 permalink raw reply	[|nested]
2022-02-06 17:56     ` Jeremy Rubin

  
From: Thibaut Le Guilly @ 2022-02-07  2:30 UTC (permalink / raw)
  To: Jeremy Rubin, Bitcoin Protocol Discussion;  dlc-dev

[-- Attachment #1: Type: text/plain, Size: 3600 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6963 bytes --]

 permalink raw reply	[|nested]
2022-01-24  8:01 [bitcoin-dev] CTV dramatically improves DLCs Lloyd Fournier
  2022-01-25 16:24 ` [bitcoin-dev] [dlc-dev] " Jonas Nick
  2022-01-28 17:21 ` [bitcoin-dev] " Jeremy

  
From: Jeremy Rubin @ 2022-03-15 17:28 UTC (permalink / raw)
  To: Lloyd Fournier, Bitcoin Protocol Discussion;  dlc-dev

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1877 bytes --]

 permalink raw reply	[|nested]