Careful Logging Contract Factory

Author: conduition

Source: https://conduition.io/scriptless/dlc-factory/

This article introduces a paradigm for creating off-chain "Discreet Log Contracts (DLCs)" and extending the contract without any on-chain transactions. I will refer to these transactions as a "factory", because we only need one on-chain funding transaction to create an unlimited number of DLCs. You can think of them as "infinite DLCs" or "self-extending DLCs".

• The DLC factory can be extended infinitely without any on-chain transactions. Either party can break the contract or settle early within a pre-determined window.
• The DLC factory is flexible and asymmetric, allowing us to create financial instruments similar to financial options contracts and contracts similar to stablecoins (where BTC can be redeemed at a fixed USD value at any time).
• No new trusted third party is introduced. Only a passive oracle is required, which is no different from traditional DLCs.

Transaction Flow Diagram

Establishment Process

• Prepare a 2-of-2 multisig UTXO funding to be shared between Alice and Bob. The shared rights over this are represented as "A + B" in the diagram.
• Create two commitment transactions that spend the funding output, one for Alice and one for Bob.
  • The commitment transactions can optionally set an absolute timelock to prevent the holder from publishing it prematurely.
  • The commitment transactions have 1 input and 1 output *.
  • Alice's commitment transaction can be spent by:
    • Both Alice and Bob signing; or
    • Bob signing, and either:
      • Having any valid attestation for that DLC; or
      • Having a liquidation attestation associated with another related DLC (optional)
  • Bob's commitment transaction can be spent by:
    • Both Alice and Bob signing; or
    • Bob signing, and either:
      • Having any valid attestation for that DLC; or
      • Having a liquidation attestation associated with another related DLC (optional)
• For each commitment transaction, create a settlement transaction that spends the corresponding commitment transaction output.
  • The settlement transactions have 1 input and 1 output *.
  • The settlement transactions have a relative timelock, denoted as "$\Delta$".
  • The settlement transaction output can only be spent with signatures from both Alice and Bob.
• From the settlement transaction outputs of Alice and Bob, create two sets of DLC Contract Execution Transactions (CETs).
  • A single CET can only spend one settlement transaction - they are fully mutually exclusive.

* These transactions require an anchor output to deal with the volatility of the transaction fee market.

Once the structure of the contract transactions is agreed upon by both parties, He Yi and Block can take the appropriate oracle as the adapter point, sign all the CETs.

Finally, He Yi and Block cooperatively sign the commitment and settlement transactions, but crucially - each party only receives the counterparty's signature on their own version of the commitment/settlement transactions, i.e.: He Yi receives Block's signature on He Yi's commitment and settlement transactions, while Block receives He Yi's signature on Block's commitment and settlement transactions. However, to prevent griefing, both parties need the counterparty's adapter signatures on the two sets of CETs. I will explain this asymmetry in the "Analysis" section.

After exchanging the signatures, both parties can sign and publish the funding transaction. Once the transaction is published and confirmed, the DLC factory is activated. The party that signs last effectively gets a free option (to decide whether to publish or not), but regular DLCs also have this, which is a known open issue.

Settlement

If one party wants to unilaterally settle a DLC factory, they first need to decide which DLC to settle, then publish the commitment transaction for that DLC. The timelock (if any) on that commitment transaction must have expired, and the DLC's attestation must not have been published yet; and the settlement transaction's relative timelock must not have expired either before the settlement transaction can be published.

Then, we publish the settlement transaction, which will fully lock in a specific DLC. Once the settlement transaction is confirmed, the entire contract becomes just like a traditional DLC: waiting for the oracle's attestation to be published, and once published, that attestation can be used to unlock and broadcast one of the CET with the adapter signatures.

This is why both parties need to receive the counterparty's adapter signatures on the two sets of CETs: for example, if He Yi doesn't have Block's adapter signature on Block's CET, then Block can extort He Yi - he can publish his commitment/settlement transactions, and He Yi won't be able to publish any CET on Block's behalf; if the oracle-attested outcome is favorable to He Yi, Block can just disappear and not let He Yi take the funds that should be hers.

To cooperatively settle a DLC factory, He Yi and Block can negotiate a new DLC they want to fund. By default, this can be one of the DLCs they have already agreed to execute, but it can also be adjusted as needed. Once they reach an agreement, they create a cooperative close transaction that spends the funding output, and then sign a set of CETs that spend this cooperative close transaction. These CETs will split the funds according to the oracle attestation that He Yi and Block have already agreed on, and these CETs will be the final set they sign for this DLC factory contract.

He Yi and Block can cooperatively sign and publish the cooperative close transaction, and then proceed to execute a regular DLC. If either party stops cooperating, the other party can revert to the unilateral settlement mode and publish one of their commitment transactions.

Punishment

Note that once the settlement transaction is published, both parties can safely go offline, even if the DLC attestation has already been published. However, prior to that, He Yi and Block must remain online and vigilant: if the counterparty publishes an old, outdated commitment transaction, they need to punish the counterparty. That is, they need to publish a punishment transaction that takes all the value from the commitment transaction output before the relative timelock $\Delta$ expires.

Furthermore, like in Lightning channels, this punishment mechanism can be independently executed by an untrusted watchtower on behalf of the participants. The only change is in the punishment path, where He Yi and Block have both adapted-signed a punishment transaction that can be completed with any of the oracle's attestations. So the participants can give these transaction copies and pointers to the oracle's attestations to the watchtower. The watchtower can then unlock and publish the punishment transaction if it detects the publication of an outdated (for which the corresponding attestation has already been published) commitment transaction.

If a DLC is cooperatively settled, this watchtower cannot directly know which funds are involved in that contract, although it can know the relevant amounts and the oracle event involved.

Analysis

This structure allows He Yi and Block to enter into multiple mutually exclusive DLCs with each other, and either party can settle using any DLC in the factory, as long as the attestation for that DLC has not been published and will not be published within the relative timelock window after the commitment transaction confirmation. If the attestation will be published within the timelock window, the counterparty can take all the value from the commitment transaction. This constitutes a final deadline for He Yi or Block to safely publish their own commitment transaction.

What is the use of this structure? It can extend a DLC indefinitely without the need for on-chain transactions. Extending a DLC factory contract is very simple: you only need to sign a new set of CET, settlement transactions, and commitment transactions using a new set of oracle announcements. The old DLC can still be executed before the aforementioned time point. And after reaching the above time point, the new DLC will take over, because neither party can safely publish the old commitment transactions anymore. If the two parties cannot mutually agree to extend this DLC factory, either party can directly publish a commitment transaction to lock in the execution of a specific DLC.

Therefore, the DLC factory allows us to create multiple financial contracts that settle at different time points, rather than just creating contracts that expire at a fixed time.

For example, Alice and Bob can create a contract for difference (CFD), where both parties agree to pay each other a certain amount of money based on the price of a specific underlying asset (such as gold, a stock, or even BTC). This type of contract can already be implemented using DLC, but previous Bitcoin DLC approaches always assumed that the CFD contract had a fixed expiration date, while in traditional exchanges, CFDs can be settled at any time and can be extended indefinitely. The DLC factory can now allow Bitcoin to simulate the very flexible features of CFDs, allowing short-term traders to price them.

We can also use this method to create other more complex financial instruments. Since the commitment transactions are asymmetric, we can create completely different DLCs for the two parties, so that which DLC is settled will depend on which party publishes the commitment/settlement transaction. We can also prevent one party from initiating the settlement by simply omitting their commitment transaction. We can create:

• Differential contracts where the payout is adjusted based on the identity of the party initiating the settlement.
• Option-like contracts - only one party can "exercise" the contract.
• Stablecoin-like contracts - where the contract holder can redeem their BTC for a fixed amount of USD at any time.
  • The other party effectively gets the opposite contract: using their Bitcoin holdings to acquire more Bitcoin (if Bitcoin's price drops), which one can imagine some Bitcoin enthusiasts would love...

Modifications

DLC factories can be customized in various ways to suit specific use cases.

• Absolute time locks on the commitment transactions can be used to define priorities, so that at any given time, only a subset of commitment transactions can be broadcast. For example, a DLC factory might assign a DLC for each day, with each DLC having a commitment transaction that can be enabled at 8 AM, and the corresponding event being announced at 11 AM. If $\Delta$ is 1 hour, participants will only be able to safely publish the commitment transaction for that day's DLC between 8 AM and 10 AM. Publishing after 10 AM would allow the counterparty to use the punitive branch to steal all the funds.
• Different time locks can also be set for the two parties, so that at certain times, only one party can "lock in" a DLC, while the other cannot. For example, one party could settle the DLC factory at any time, while the other party can only initiate settlement during business hours on business days.
• The punitive branch of the commitment transaction outputs can use a time lock instead of a witness lock, so that if the commitment transaction is published after a certain time, all the funds are sent to the counterparty. This feature may be useful if the oracle's witness is very timely, but privacy against the watchtower is highly important, as it does not give the watchtower any information (other than the total value involved in the DLC factory).
• The commitment transaction outputs can be set up with an additional punitive path that uses a revocation secret value like in Lightning channels. This will allow participants to manually void future commitment transactions, enabling negotiation of future DLCs within the factory.
• The CET can be made asymmetric, with differentiated payout curves based on the role of the party closing the factory. For example, the CET held by the closing party could give them a slightly worse payout curve than the counterparty, to incentivize both parties to cooperatively close the factory rather than one party forcing a unilateral closure.
• The funding outputs can also be made to include an HTLC condition, allowing the ownership to be trustlessly transferred via on-chain transactions; this would allow people to use the Lightning network to take a position in a DLC factory (requires further research).

Drawbacks

With advantages come drawbacks.

Performance

Signing and verifying DLCs involving numeric outcomes is already very difficult, as it often requires a large number of CET adapter signatures. The DLC factory will be even slower, as each DLC is asymmetric and requires two sets of CET. And of course, each additional pair of commitment transactions requires an extra signing process. The signing/verification performance is best for options-like contracts, where only one party has the ability to publish the commitment transaction.

While the performance cost of DLC factories is high, the cost can be amortized over time, as the commitment transactions do not necessarily need to be signed until close to expiration. So participants can choose to first sign a DLC, then fund the contract, and gradually add the remaining CET signatures over time.

Liveness

DLC factory participants become liveness-requiring.

In traditional DLCs, the two parties can be offline even after the contract expires. If the oracle's witness is not to your liking, you can simply go offline and let the other party settle the DLC.

But DLC factory participants, like Lightning channel peers, must actively monitor the blockchain to ensure the counterparty does not publish old commitment transactions and steal the funds using outdated witnesses. Each party must ensure they have the ability to timely submit the commitment transactions, which requires them to stay online.

This drawback can be mitigated by using watchtowers.

Deadlock

DLC factory participants must also ensure that if the counterparty is unwilling to sign a new set of commitment transactions and CET to extend the factory's life, they can timely publish a commitment transaction. Otherwise, the factory may enter a deadlock state: neither party can unilaterally dissolve the DLC factory on-chain, unless both parties come back online and cooperatively construct a closure.

This is similar to Lightning channel participants generally forcibly closing the channel after the counterparty has been offline for a long time, except that in the DLC channel, there is a clear time point at which the factory must settle to ensure the funds can be fairly withdrawn.

Real-world Events

DLC factories are also not well-suited for witnessing real-world events with flexible release dates.

First, the benefits are limited: if an event only happens once, why would you want to extend the life of a DLC factory?

Furthermore, if a witness may be released earlier - for example, a sporting event is canceled - the DLC factory's commitment transactions may unexpectedly become invalid. In this case, it would be useful to add an absolute time lock to the punitive path of the commitment transaction outputs, so that the parties can commit and settle a DLC if the witness is published much earlier than both parties expected. Of course, this form of contract works well for continuous, constantly refreshing, and predictable witness sources, such as financial asset prices.

Settlement Transactions

You may wonder: why set up settlement transactions?

Imagine a DLC factory that does not set up settlement transactions, where the CET is directly spent from the commitment transaction outputs. In this case, no commitment transaction can ever be published.

Before the assertion witness is revealed, the CET cannot be spent. However, once the assertion witness is revealed, the punishment path is also opened! The best outcome is a race between the parties to spend the commitment transaction outputs.

We need a staged transaction to lock in the DLC. This is the purpose of the settlement transaction.

Note: If we design the punishment mechanism slightly differently, letting subsequent DLC witnesses (or their expected publication time) settle the punishment branch, the settlement transaction can be omitted. This way, the CET can be enabled before the punishment branch becomes available. Is this a good design? It depends on your use case.

Comparison with DLC Channels

"DLC factories" may sound similar in principle to "DLC channels": both allow participants to create many DLCs and cooperatively update or settle them off-chain. However, the two differ fundamentally in their use of time locks and commitment mechanisms. These differences make DLC factories superior for certain use cases, while DLC channels are better suited for others.

The key difference lies in how old states are revoked.

In DLC channels, commitment transactions must be manually revoked by the contract holder, by handing over a revocation secret to the counterparty. If an old commitment transaction is not manually revoked, it remains valid and can be published on-chain at any time, locking in a specific DLC.

In DLC factories, commitment transactions are generally automatically revoked, either through an assertion witness and/or an absolute time lock. Thus, DLC factory commitment transactions have an inherent, unavoidable expiration date, and no party can prevent the revocation from happening.

When using DLC channels, you establish a channel, sign a DLC, and then you have a unilateral exit option, but only for that specific DLC. Even if you try to pre-sign many DLCs with future expiration dates, you need your channel counterparty to actively revoke them after those DLCs expire - otherwise, your counterparty can publish an old commitment transaction and defraud you. You'll have to go back on-chain to eliminate this possibility.

In contrast, in DLC factories, your counterparty's commitment transactions will be automatically revoked by the assertion witness, or by an unstoppable ticking time lock, regardless of whether they cooperate. This means that you and your counterparty don't need to worry about the other party being online. You can both happily pre-sign any number of DLCs with future expiration dates, knowing they will all be revoked at the pre-agreed time (because the commitment transactions have a revocation path).

The difference can be summarized as: good factories run automatically, but channels can only be manually changed.

Another perspective is that DLC factories are very similar to DLC channels, except that the revocation secret is independently and accidentally distributed by the assertion oracle. This subtle design choice gives DLC factories very different pros and cons.

Conclusion

I've written extensively about DLCs before, and you've probably gathered that I'm quite fond of them. DLCs are one of the most flexible ways to create Bitcoin smart contracts, and they can be used to emulate many traditional financial instruments, as well as create some entirely new ones.

If you have ideas for developing DLC factories, or suggestions for optimizing the concept, please let me know!

(End)