The recent activation of the Taproot soft fork is a major milestone for Bitcoin, bringing with it exciting new possibilities for innovation and application. One such innovation is the Discreet Log Contract (DLC), a concept first introduced by Taddeus Dryja. By leveraging the Schnorr signature implementation on libsecp256k1, DLCs represent a critical piece of infrastructure for the Bitcoin ecosystem. However, as with any new technology, it must be carefully specified and used responsibly. Fortunately, we're already seeing the first product releases based on DLC specifications, and the team at LN Markets is eager to explore this exciting new technology. So let's take the plunge down the DLC rabbit hole and see where it takes us!

In this initial post, we provide a high-level explanation of the issues addressed by Discreet Log Contracts (DLCs) in comparison to existing solutions and the cryptographic techniques employed to achieve these goals. In a second post, we will delve into the different proposals for the cryptographic components involved. Finally, in our last post, we will explore the practical implementation of DLCs specifically for derivatives trading.

Conditional payments

Usual payments as a particular case

In the world of finance, simple payments triggered by the owner's coins or account acceptance are at the foundation of the banking system. However, for more complex financial agreements such as bets, hedges, smart-contracts, and derivatives, more sophisticated payments are needed. These payments are conditioned to a specific real-world event, and are triggered by an attestation in the ledger, rather than the owner's authentication. This type of payment is known as a conditional payment.

The challenge is that a ledger is just that - a record of promises we've made to each other without any connection to the real world beyond those who transact with it. That's why an attestation from someone, directly or indirectly, that a certain event has occurred is necessary. This attestation becomes the trigger for a payment without the need for payer authentication. This is what we call a conditional payment. Lightning Network's Discreet Log Contracts (DLCs) unlock new possibilities for conditional payments that weren't previously possible.

Conditional payments and custody

In the world of conditional payments, it's possible for payers to not have full custody of the funds that will be sent when a specific event occurs, as the payment can be triggered without their signature. This process typically involves two distinct steps: funding and payment.

• Funding: Each party send the maximum amout it may lose by accepting the contract in a address that it doesn't fully control
• Payment or Settlement: Someone publishes one or several triggered transactions by the event attested that pay acording to the event

This two-step process is known as a contract, with the first step being the contract setup and the second being the contract execution. It's worth noting that there may be additional steps between these two stages.

While a contract is ongoing (funded but not settled), any party that may have to send money if certain events occur will have lost full custody of the funds they promise to send and must wait for contract execution to get them back. A contract is settled for a contracting party as soon as there are no more funds that they may receive from it.

Simple cooperative case

Let's start our explanation with two characters, Alice and Bob, as every cryptographer would do. They want to bet on the winner of a match between the Azure team and the Blake team, settling the bet with Bitcoin. In an ideal world where promises are always kept, Alice would pay Bob if she loses, and Bob would pay Alice if he does. This cooperative settlement of a contract is advantageous when possible. No third party is required, and the parties' privacy is preserved because the contract settlement is a normal transaction.

However, in reality, there is a strong incentive for each party to not pay if they lose the bet. In most cases, Alice and Bob agree to bet with each other, but they are not willing to trust the other party to send the bitcoins if they win. They want to be sure that they will get the money without relying on the other's consent. They want a conditional payment: Alice will only consider that Bob fully accepts the contract if he loses full control over the funds he may have to send to Alice, and vice versa. Therefore, using a third party as a custodian during the contract seems like the obvious solution.

Escrow-based Conditional payments

Single custodian escrow

In the world of ledgers, triggering a payment is a straightforward process - just use a digital signature. However, when it comes to conditional payments, where parties must lose full control over the funds they commit in a contract, it becomes necessary to involve a third party. Enter Edouard, the trusted escrow who can provide a solution.

Assuming that Alice and Bob don't trust each other, they agree to send the funds to Edouard in advance, who then has full custody of the funds. Using his signature, Edouard can attest which team won and trigger the contract settlement by signing a transaction sending the funds back to the winning party.

This setup is known as a single escrow-based payment and is commonly used in custodial exchanges. Its main advantage is that the contract may involve any number of parties.

In a single Escrow-based payment:

1. Contracting parties announce their intent in contracting to the escrow
2. The escrow acknowledges he will handle the contract and provides an address he owns
3. Contracting parties send funds to the escrow
4. The escrow waits to observe the outcome
5. And sends funds back to the contracting parties according to the contract rules

However, it has its drawbacks, primarily the issue of custody by the escrow who can potentially steal the funds. Additionally, since it is centralized, any issues with the escrow can result in the loss of funds even if the escrow was honest, even if Alice and Bob are both willing to settle the bet cooperatively.

Multi-sig escrow

A better approach to the previous method is to use a 2-of-3 multi-signature address, which involves Alice, Bob, and Edouard. This allows Alice and Bob to contract together using Edouard's public key. If they both agree on the outcome, they can use their signatures to pay the winner. However, if they do not agree, they can inform Edouard of the contract and he can provide a signature to the transaction that pays the winner, who can add their signature to claim the funds.

In a multi-sig Escrow-based Payment:

1. Contracting parties may announce their intent to contract with the escrow
2. Send funds into a 2-of-3 multi-sig address using escrow public key
3. May wait for the event to happen and settle cooperatively
4. Else resolve the dispute with the escrow:
5. The escrow learns/reads the contract, attests for an outcome
6. Signs a transaction to distribute the funds according to contract rules
7. The winning contracting party sign and broadcast the escrow's transaction

This type of setup is suitable for P2P exchanges like BISQ or Robosats because it offers greater privacy in cooperative cases but is only possible for contracts that involve the redistribution of funds between two parties (ensuring that there is always a winner who can sign the transaction with the escrow).

One advantage of this approach is that Edouard can no longer simply steal the funds, and cannot prevent contracting parties from settling cooperatively and even never know about it in that case. However, the losing party may try to make it impossible to contact Edouard for settlement or contact Edouard first and trick him into signing the wrong transaction by lying about the contract.

Issues with Escrow-based Conditional payments

In any Escrow-based Conditional payment that involves the third party escrow, Edouard, he must perform the three following tasks:

• Interpretation: Understand the contract between Alice and Bob correctly
• Attestation: Decide what is the real outcome he should attest
• Execution: Sign a transaction that distribute the funds of the contracting parties according to rules of the contract for the attested outcome

Unless they are really ready to face the risk to avoid revealing the contract to the escrow, it is crucial for Alice and Bob to inform Edouard of the contract before a dispute arises. Otherwise, Edouard may be tricked into misunderstanding the contract terms and signing a transaction that benefits one party over the other. For example, if Bob falsely claims that he mistakenly sent funds to the 2-of-3 multisig address, which includes Alice's public key, Edouard may unintentionally defraud Alice by signing a transaction that returns all the funds to Bob.

To avoid such mishaps, Alice and Bob must explicitly declare their intention to contract with Edouard and ensure that he fully understands the contract terms. Edouard may even attests to his understanding with a signature. This way, if Edouard makes a mistake in the future, Alice and Bob can prove that he did not execute the contract correctly, and other parties can see that Edouard should not be trusted.

Although Escrow-based Conditional payment is a practical approach, it has a significant drawback because the escrow is responsible for both attesting to the outcome and executing the contract. This issue is resolved in DLCs by isolating the roles of the third party, thereby removing the responsibility of contract execution from the escrow.

Oracle-based Conditional payment

Splitting events attestation and contract execution

Initially, using an escrow was deemed necessary in Conditional payments because a third party was needed to attest an event that triggered the payment settlement without any payer action. However, it's not necessary for the third party to sign a transaction to distribute funds as in Escrow-based Conditional payments. A better solution involves splitting the different parts of a Conditional payment.

The third party is only necessary to attest an event. As in the case of a multi-sig escrow-based payment, the contracting parties can have shared custody of the funds but restricted to both of them, as in a payment channel in the Lightning Network. Thus, the third party can simply attest to the event, and the contracting parties can unilaterally claim the funds of the contract through the attestation of the third party.

This semi-trusted third party is called an oracle. Contracting parties trust that the oracle will attest to the correct outcomes when the event occurs, often through a digital signature. They don't trust the oracle to decide how funds should be distributed next, nor do they lend any funds while the contract is ongoing. There is no need for dispute resolution with the Oracle; it only attests the event and lets the contracting party claim their reward by themselves. This is called an Oracle-based Conditional (ObC) payment.

The main cryptographic primitive: verifiable encryption

To enable third party oracle Olivia to attest outcomes and allow Alice and Bob to unilaterally claim the results of their bet based on her attestation, certain steps must be taken by Olivia, Alice and Bob.

Olivia, using her private key, must sign a message related to the event she is attesting with her public key among a list of possible outcomes. To keep the contract off-chain, Alice and Bob must exchange partial signatures that spend the funds of the contract according to each payout allowed before funding it. These presigned off-chain transactions are known as Contract Execution Transactions or CETs. One CET must be presigned for each possible payout.

But each contracting party must not be able to use the other party's signature of a CET without a corresponding attestation's signature of Olivia (one-wayness property). Therefore, the partial signatures must be shared encrypted using a public key linked to Olivia's signature over the outcomes corresponding to a given CET. However, a problem arises when Bob sends the encrypted partial signature to Alice (and conversely). She needs to verify that the data she received is indeed an encrypted signature from Bob of the CET that she can decrypt using Olivia's signature of a certain message. Otherwise Bob could just send random data to Alice and make it look like a signature encrypted, To address this, they require verifiable witness encryption. This is an encryption that allows to verify thanks to a proof that the encrypted data will verify certain property when decrypted without using the secret key needed to decrypt the data.

The steps of an Oracle-based Conditional payment in binary outcomes

The ability to verify that some encrypted data have certain property is the missing piece that allows Alice and Bob to setup a contract where the only task of Olivia is to attest an event by signing the outcome with her private key.

The typical setup for an Oracle-based Conditional payment using such cryptographic primitives is as follows:

• Olivia is a known oracle. She advertise that she will attest who is the winner of the futur match between Azure and Blake team by signing the name of the winning team.
• Alice and Bob believe respectivly that Azure and Blake team will win and engage in a bet. They construct a multi-sig 2-of-2 address and prepare a funding transaction.
• They prepare all CETs spending the funding output according to rules for each possible payout and sign them individually. Here there are only two possible payouts: everything for Alice or Bob respectively if Azure or Blake win respectively.
• They use the encryption method of the verifiable encryption scheme on each CET's signature using the name of the teams, with Olivia's public key and exchange the results and proofs
• They use the verification method of the verifiable encryption scheme to check that they will be able to build a signature for each CET with corresponding Olivia attestation
• If everything checks out, they exchange signatures of a refund transaction with a sufficiently long timelock and sign and broadcast the funding transaction to the multisig address. Contract is setup.

After the match, Olivia attests the result, allowing Alice and Bob to settle the payment:

• Olivia signs the winning team (let's assume it is Azure)
• Alice wins the bet, she can claim the reward from Bob directly. If Bob acknowledges his loss and signs a transaction that sends all the funds to Alice, then the contract is settled cooperatively.
• However, if Bob disputes the result, Alice can use Olivia's signature of "Azure" to decrypt the previously encrypted signature that Bob provided corresponding to her payout in case Azure wins, allowing her to claim all the funds.
• In the event that Olivia is unable to attest to the result using her private key, Alice and Bob can retrieve their funds using the timelocked signature after a certain period of time has elapsed.

Conclusion on Oracle-based Conditional payments advantages

Contracting involves the process of making conditional payments, and in Bitcoin, payments are typically conditioned on the revelation of a digital signature. However, they cannot consider real-life events to trigger these payments.

As a result, a third party is needed to attest the event that triggers the conditional payment. Many existing solutions in Bitcoin rely on a trusted escrow who interprets and executes the contract based on the attested event.

Oracle-based conditional payments address this issue by removing the escrow's responsibility for interpreting and executing the contract. Instead, the escrow acts as an oracle, simply signing the facts of the event.

To enable such payments in Bitcoin, an efficient verifiable witness encryption for Bitcoin signatures is required. In our upcoming post, we will discuss different proposals with their respective advantages and disadvantages. The well-known Discreet Log Contract is a prominent example of a proposal for verifiable witness encryption. In a third post, we will explore how we can handle more complex outcomes, such as price-based scenarios.