Supercharging DLCs with CTV

CTVs make DLCs small, efficient, scalable, and generally more secure with few downsides.

Note: As with my last post explaining CTV I will elide, skip, and shorten content for the sake of brevity and plain language explanations. If you want perfect technical accuracy then read the linked posts in the citations down below. I'd also recommend first reading my post explaining CTV if you are new.

One of the best places to go for discussion on Bitcoin is the bitcoin-dev mailing list but the content there is often terse and highly technical.

So today I want to breakdown a recent post by Lloyd Fournier that covers the possible improvements CTV can bring to DLCs. I learned quite a lot and hope to pass this information on to a broader audience.

Ok, What are DLCs?

Today you can create a bet on the price of Bitcoin with something called a Discreet Log Contract ("DLC"). This is a clever bit of cryptography that allows for 3rd parties (aka oracles) to attest that a certain event happened. This attestation can then be enforced by the Bitcoin network so that it can enforce a previously agreed bet.

A Future Contract as an Example

First, let's take a look at a concrete example of a DLC between Alice, a diamond hand OG Bitcoiner, and Bob a no-good Keynesian who idolizes Paul Krugman.

Alice and Bob will create a Future contract between them which can be understood and enforced by the Bitcoin network with DLCs. A Future refers to a bet on the future price of thing; in this case Bitcoin.

Alice, being a good Bitcoiner, will bet that the price of Bitcoin is $100,000 on Jan 1st 2023. Bob will bet that it won't. Bob sucks.

To complete this bet Alice and Bob will agree on 3 price oracles and require at least 2 of the 3 to agree.

On Jan 1st 2023 all 3 oracles declare the following BTC/USD prices:

• $101,002

• $100,999

• $100,999

The oracles all sign their messages using cryptographic signatures. Alice and/or Bob can then use these signatures to settle the bet with their DLC. Perfect!

Alice and Bob, having agreed around the $100,000 price find that neither of them can complete this contract. The price isn't $100,000, and none of the oracles knew about the bet so they've not published a valid message and signature saying the BTC/USD price is exactly $100,000.

Now, this isn't how people use DLCs today, what they would have done is create many, many bets on the price of BTC/USD (using adaptor signatures). In this example they'd effectively make one bet for every dollar BTC/USD could fluctuate above or below $100,000. Alice would take all bets greater than or equal to $100,000. Bob would take all bets $99,999 and below. This is a big number. It would be an even bigger number if they bet out to pennies.

Reducing Complexity with CTV

As Lloyd Fournier puts it Alice and Bob would "end up sending data on the order of megabytes to each other" for just this single bet. This is a lot of data for one bet and it scales very poorly for many bets.

They'll also need to store this data and end up choosing a small number of oracles for practical reasons. According to Lloyd, a present day 3 of 5 DLC has 10x the computational complexity of a 2 of 3.

With CTV almost all of this heavy computation would go away. Alice and Bob would not need to exchange and store megabytes of data. They'd simply do a few very small computations and be on their way; no need for calculating tons of adaptor signatures. This scales much better.

They'd also be able to use as many oracles as they please with only a small amount of data needing to be computed and exchanged for each additional oracle. For example: a CTV DLC's work increases by 5x when going from 2 of 3 to 3 of 5. But this is still much less work than present day DLCs because Alice and Bob are 5x'ing a very small number with CTV and 10x’ing a very large number with present day DLCs.

EDIT: CTV also allows for non-interactive creation of DLCs which is arguably a huge improvement as well. What this means is that today, when Alice and Bob want to create a DLC they both need to be online at the same time and exchange a lot of data. With CTV they'd be able to propose and accept DLCs with each other without ever needing to be online at the same time to create it. They can contribute their parts without coordinating. Thanks to buck for pointing out this additional benefit!

Downsides of CTV-based DLCs

I want my readers to be informed, so even though I am personally quite optimistic on CTVs there are some is one downside to using a CTV DLC over current day DLCs.

If Alice and Bob do not cooperatively close their CTV DLC bet then one of them will have to reveal that the exchange was a bet on the Bitcoin network. This information leakage is not the case with present-day DLCs.

This is similar to Lightning channels revealing themselves when one side of a 2-party channel does not cooperate in closing the channel. Which is to say it's a rare occurrence but does happen largely due to technical reasons. Lightning channel owners and DLC users are generally incentivized to cooperate and not reveal this information.

Additional Notes

• CTV also fixes security issues in the current DLC spec. I'm not very knowledgeable on these security issues; follow the link in the citation below.

• Jeremy Rubin has an excellent article in his advent calendar that goes into Futures, Options, and even stablecoin derivatives

Thanks for reading. If you have any questions, comments, or anything I missed please leave a comment below!

Citations

• bitcoin-dev mailing list: https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

• Lloyd Fournier post on bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019808.html

• Security issues in the DLC spec: https://bitcoinproblems.org/problems/secure-dlcs.html

• Jeremy's Advent Calendar: https://rubin.io/bitcoin/2021/12/20/advent-23/