On December 17th, 2020, Roman and I (Nadav) entered into a special kind of Discreet Log Contract (DLC) called a Contract for Difference (CFD), or Discreet Log Contract for Difference (DLCFD) for short. Roman entered into the CFD with $22.80 worth of BTC, and exited with that same amount of USD even though the price of BTC moved. That is to say, if the price were to go down, then I would have to pay Roman to make up the difference so that he would exit with $22.80. If the price were to go up on the other hand, as it did, then Roman would have to pay me to make up for the difference and exit with that same fixed USD amount.
From Roman’s point of view, the CFD allows him to hold BTC without being exposed to bitcoin price volatility (assuming he is denominating his assets in USD). Whether the price moves up or down, the Contract for Difference covers the difference for him, leaving his USD value fixed. Roman’s payout curve is shown above (with oracle outcomes denominated in BTC/USD). He entered with 100,000 satoshis when the price was $22,800/BTC and you will notice that if the price does not move, then 100,000 satoshis will again be his payout. If, on the other hand, the price moves down, he is compensated in BTC terms, and if the price moves up, then he loses satoshis to stay at a fixed USD value. Another way to see this is if we were to re-plot the above payout curve, denominating payout in USD instead of sats, it would just be a flat line at $22.80 for any outcome.
From my point of view however (the upside-down version of the payout curve above), this is a type of long position on BTC relative to USD, meaning that I am speculating that the BTC/USD price will rise resulting in Roman paying me the difference.
In some ways, the existence of DLCFDs allows for the decoupling of holding/using BTC from the price exposure that is usually associated with such activity. So long as there are those interested in taking long positions on BTC/(Other Asset), then entities such as businesses can match with them to create CFDs which leave their funds fixed in (Other Asset) terms for any period of time. And when this entity wishes to pay someone in BTC, they can do so atomically with exiting the CFD so that from their perspective, they were hardly ever exposed to BTC price volatility while still being able to use BTC as a payment infrastructure.
Now that we know what a Contract for Difference is, and some of its uses, let’s dive into some of the details as to how we can execute DLCFDs on Bitcoin. A DLC consists of a single on-chain funding transaction, and a set of off-chain transactions called Contract Execution Transactions (CETs). There is a single CET for every possible outcome and the outputs on the CET reflect each party’s payout for that outcome. Each CET spends the on-chain funding transaction’s 2-of-2 multisignature output and the oracle contract is enforced by making this spending contingent on an oracle signature of a specific message unique to that CET. To learn more about how DLCs work, check out our previous blog post series or the DLC work-in-progress specification which has additional resources.
As we discussed in the blog post about our previous (volatility) DLC, this scheme supports an arbitrary number of outcomes (and hence arbitrary oracle contracts) in theory. However, in practice we need to compress our set of outcomes to a reasonably small number to accommodate communication and computational constraints. We discussed how continuous intervals of constant-valued outcomes can be compressed into negligible sizes by having oracles sign each binary digit (aka bit) of the outcome individually. This allows us to ignore the least significant digits to construct transactions that cover many outcomes, for example if the last 10 bits can be ignored (as no matter their value the payout is the same), then we can construct a single transaction which covers 2^{10} = 1024 outcomes at once. This means we only need to create, send, and store a single adaptor signature in place of 1024!
Our oracle, Skrik, committed to signing the BTC/USD price as 17 binary digits (supporting all values between $0/BTC and $131,071/BTC).
In our volatility DLC, we used this compression trick to cover all cases that were not in our expected price range of $17k-$21k all the way up to $131,071 with fewer than 20 CETs! However, you’ll notice that in the case of a CFD, only one side has a constant-valued collar, and there are far fewer cases that must be covered. This is where our first new tool comes into play: Rounding Intervals.
During contract negotiation, Roman and I agreed that we were comfortable rounding our payouts to the nearest 100 satoshis for all outcomes, and to the nearest 1,000 satoshis for any outcome beyond $30,000 (noting that even if BTC is worth $130k, 1,000 satoshis is still only worth $1.30, a small portion of the locked up assets). Our willingness to do this rounding enables us to use our CET compression algorithm everywhere, instead of only for collars. Specifically, it allows us to take advantage of any flatness (non-steepness) along the payout curve because if the curve is relatively flat, then we can round large sections to the same nearest 1000 satoshis and compress that interval.
How effective is this scheme? Well, here are some numbers computed for our DLCFD:
- Without rounding: 86,718 CETs which requires significant computing time as well as ~65MBs of data over the wire.
- Rounding everything beyond $30k to the nearest 1,000 satoshis: 20,547 CETs which requires ~15MBs of data over the wire.
- Note that this is about the number of values between 10k (where the collar is) and 30k. Essentially the mostly flat part of the curve after $30k has been compressed into a negligible number of CETs!
- Rounding to the nearest 100 satoshis on $0 to $30k and the nearest 1,000 satoshis afterwards: 5,511 CETs which requires only 3.5MBs of data over the wire!
- Note that even rounding to the nearest 100 satoshis (1-3 cents) on the steepest part of the payout curve resulted in a ~4x improvement in the number of CETs!
If you are interested in more details, rounding intervals are included in the numeric outcome proposal and implemented on an experimental branch of bitcoin-s.
The second novel tool that allowed us to execute this CFD was Antoine Riard’s Non-Interactive Protocol proposal. When Roman and I initially broadcasted our funding transaction, I immediately realized that we had made a mistake. We had agreed on a fee rate of 50 sats/vbyte without checking to see if this was reasonable, and average fees at the time were well over 100 sats/vbyte! Rather than requiring that we reconnect to each other and set up a new contract forcing us to re-sign thousands of CETs, I instead unilaterally bumped our fee using Child Pays for Parent (CPFP) which is simply the act of spending on output on a too-low-fee transaction with a too-high fee transaction so that the average becomes reasonable and both transactions become desirable to miners (they cannot have the child alone as it is only valid if the parent is confirmed as well). Thus, I broadcasted a CPFP transaction which caused our funding transaction to be confirmed, all without requiring any interaction between me and Roman. If I had been foolish again and my CPFP transaction did not pay enough in fees to cover its parent, then I could have used Replace by Fee (RBF) which I enabled on my unilateral transaction to replace the child with a higher-fee child.
We also used the Non-Interactive Protocol’s CPFP mechanism to confirm our CET which again, used 50 sats/vbyte so that Roman broadcasted a child transaction to cover the fees.
In the end, our oracle broadcasted signatures corresponding to the outcome $23,427/BTC and you will notice that in our CET, Roman’s payout is 0.000974 BTC corresponding to (23,427 * 0.000974) = $22.82 which is within our rounding agreement (of 100 sats = $0.023) of his initial dollar amount of $22.80!
As was mentioned in our last post, in the near future there will be support for threshold oracle schemes, such as using 2 of 3 oracles to execute a CFD. I am currently working on a proposal for how this should be done, which will be released on the specification repository very soon!
A more long-term, but still very important, additional improvement is support for DLCFDs on the Lightning Network. On-chain CFDs are fully supported by our current code, but they only really make economic sense today for larger amounts due to high fees. Not only will Lightning DLCFDs allow contract execution to be virtually fee-less with near-instant confirmation, but Lightning DLCFDs can even be used to enable trustless version of Rainbow-esque synthetic assets in channels which are liquid (i.e. spendable)!
Stay tuned for more updates and progress on Discreet Log Contract development and other cool stuff we’re working on at Suredbits!
Feel free to connect with us on Twitter @Suredbits or join our Suredbits Slack community.
If you are interested in setting up a bitcoin-s wallet, check out the bitcoin-s documentation.