Research Summary - Discreet Log Contracts

Citation

Link

Core Research Question

  • Is there a way to create smart contracts on the Bitcoin blockchain that are triggered by external data signed by an oracle, while keeping contract execution scalable and private?

Background

  • Blockchains are distributed networks of nodes that generate consensus on a set of transactions using mechanisms such as Proof of Work or Proof of Stake. Blockchains aim to prevent the “double spending problem” where the same funds are used multiple times.
  • Smart contracts are pieces of programmatic logic created by users that are hosted on a blockchain network. Every state change is initiated by a private key holder and is both executed and verified across every node in the blockchain network.
  • Oracles are off-chain agents that connect on-chain smart contracts to external resources such as data APIs that reside outside of the blockchain network. Such data is often required in the execution of automated smart contract applications.
  • Lightning Network is a layer 2 solution for the Bitcoin network which uses bidirectional payment channels and allows for instant payments by the passing of signed messages which can be published on-chain at any time to settle the contract.
  • Futures contract is a financial agreement that provides the obligation to buy or sell an asset at a predetermined price at a specified time in the future, between two parties who may not know each other.

Summary

  • Discreet Log Contracts (DLC) are smart contracts on the Bitcoin blockchain that allow for the creation of privacy-preserving futures contracts for any asset where the contract is settled in BTC, the native Bitcoin currency.

Method

  • Discreet logs contracts involve three parties throughout the contract’s lifecycle, referred to in this paper as Alice, Bob, and Olivia. The first two parties, Alice and Bob, are the contract counterparties, while Olivia is the oracle who is responsible for signing price data that settles the DLC. Alice and Bob do not need to know each other’s identity but they require a secure communication channel. Olivia does not need to be aware of either counterparty, only needing to broadcast signed data.

  • Discreet log contracts are enabled through the usage of Schnorr signatures, but not in a typical fashion. Normally a public key A is created by multiplying scalar a by a group generator G, but in the case of a discreet log contract, the public key also consists of an additional value R, which is generated by multiplying an additional value k by a group generator G. As a result, the same Schnorr signature equations used are the same, but the value R has been reclassified as part of the public key instead of the signature.

  • Olivia uses this Schnorr signature equation to publish value V, which is her public key made up of a scalar v multiplied by the group scalar G. The value v can be made up of keys from different parties, allowing for the decentralization of the oracle used. Olivia also publishes a value R with random scalar k used as a one-time key used to sign the data. Additionally, Olivia publishes metadata about the data that will be signed using R key, such as the asset type and the closing time.

  • To create a DLC, the two counterparties must have their funds within a 2-of-2 multisig, meaning both parties have to sign a transaction to spend from it, similar to the creation of a channel on the Lightning Network. After the funding of a multisig, each counterparty generates and holds thousands of transactions off-chain, which represent every possible outcome of the contract (each possible value signed by the oracle). Because funds can only be spent once, only one of these transactions will make it onto the blockchain, and which transaction used is determined by the signed message from Olivia.

  • To prevent one of the counterparties from broadcasting a signed message and taking the funds early, the output of each transaction is not sent directly to the user but instead to an address determined by the oracle’s signed message, which cannot be falsified by either counterparty.

  • Additionally, each transaction has a timeout attached that allows the opposing counterparty to withdraw funds after a delay. This means if one counterparty tries to execute the wrong transaction, it results in an output they cannot claim but allows the opposing counterparty to withdraw all funds after a delay, preventing fraud as a malicious actor would willingly give up their funds.

  • To settle the DLC, the oracle Olivia waits until the market closure of the specific asset being tracked, such as the exchange rate of YEN/BTC, observes the closing price, and using the schnorr signature scheme, a signed message is created based on the closing price. This information can be published on-chain or off-chain, and can be used by either of the counterparties to settle the DLC and pay out the appropriate parties using the corresponding transaction signed by the counterparties that include the relevant market price.

Results

  • Discreet Log Contracts have the potential to extend the use cases of the Bitcoin blockchain by allowing users to privately enter into futures contracts which can cover any number of real-world assets, trusting only the oracle itself. To external parties, DLC contracts look identical to Lightning Network transactions, ensuring external parties do not know the terms of the agreement and the only data revealed is the final execution.

  • The oracle, Olivia, is able to mis-report the price, presenting a risk that a contract could falsely execute on inaccurate data. However, once an oracle engages in malicious behavior, such activity can be proven cryptographically to future contract creators. This means an oracle can only attempt malicious activity once before being removed from consideration in settling future DLCs. If the oracle attempts to sign two different prices, the private key is revealed to all parties due to the nature of how Schnorr signatures are used. If an oracle refuses to sign a price data point, then a transaction can be performed after delay to refund each counterparty in the contract.

Implications & Follow-ups

  • Further work was proposed in the paper such as the ability to enter and exit positions in a DLC before the predefined settlement date. If one counterparty desires to end the contract while the other does not, there is the potential for the initial counterparty to swap places with an additional third party, which would only require changing the contract to include a different counterparty public key.

  • Additionally, before a DLC-based contract can be created, the counterparties need to be able to find each other. This can be done with centralized matching engines, which wouldn’t hold custody of user funds. The paper suggests that more research can be done into decentralized matching engines.

Discussion

  • Many of the decentralized financial applications seen in the blockchain space today can be attributed to the Ethereum blockchain and its DeFi ecosystem. However, there is also a real desire to utilize Bitcoin itself within non-custodial financial agreements. While Bitcoin has been tokenized on the Ethereum blockchain (WBTC), this often requires handing over custody of funds to centralized or semi-permissioned collections of entities who hold the private keys controlling the underlying Bitcoin. With DLCs, financial applications like futures contracts could be constructed natively on the Bitcoin blockchain.

  • However, there are also open questions regarding if DLCs are generalized enough for most forms of agreements, a problem that also presents itself in other forms of Bitcoin smart contracts with limited functionality. There is also an open question regarding if DLC-based agreements would be able to overcome the network effect and adoption of the existing DeFi ecosystem, and if most users will prefer using tokenized forms of Bitcoin on another, more expressive and programmable blockchain.

Applicability

  • The Discreet Log Contract design allows for the creation of future contracts that could be based on any number of assets, given there is a secure price feed that exists. This can include a futures contract on the price of Bitcoin itself, efficiently allowing holders to sell their volatility exposure to a third party, creating a pseudo-stablecoin and allowing other participants to gain leveraged exposure to BTC on the baselayer Bitcoin blockchain itself.

  • The Discreet Log Contract design can also be combined with an existing decentralized oracle network such as Chainlink which provides a number of price feeds that provide financial market data on various cryptocurrencies, stablecoins, foreign exchanges, equities, indices, and commodities. Through the usage of an existing oracle network with nodes providing historical proof of their performance, DLC agreements would minimize trust assumptions and effectively bootstrap an ecosystem of futures contracts on the Bitcoin blockchain.

5 Likes

Is there any ongoing research into using DLC’s to bridge Bitcoin to DeFi in ways that mitigate the risks of custodial solutions such as WBTC?

I don’t believe so as DLCs are designed primarily to serve as financial agreements between two parties on the Bitcoin chain in a discrete manner. The core issue of tokenizing Bitcoin onto other chains is that the Bitcoin isn’t actually being moved to another chain, but instead an IOU is created that represents a claim on the Bitcoin, while the underlying is held by a custodian (private key or multisig). This means tokenizing Bitcoin held in a DLC agreement results in the counterparties being the custodians.

However, we’re now seeing tokenized Bitcoin become more trust-minimized with implementations like renBTC, which aims to decentralize the custody process using a multi-party computation scheme to split a single private key among many parties. There is also more trustless solutions like tBTC where a multitude of custodians hold the underlying Bitcoin using a multisig, while also being required to post a bond in the chain’s native token ETH that is worth 150% of the Bitcoin being tokenized. This means if the custodians collude and steal the underlying Bitcoin, the bond can be slashed by a smart contract on Ethereum and compensate the tBTC holder for the full value it should be worth.

So while I don’t think DLCs will help with bringing Bitcoin onto other chains, there is work underway to trust-minimize this process.

1 Like