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


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