# Intro to Transformable Discreet Log Contracts

## Introduction

Discreet Log contracts are interesting, but one of the key issues is that they lock the two participants into the contract and do not allow for mutability, unless both participants are online, agree, and are willing to allow another participant into the contract. One of our key goals is to allow transferability of DLCs only requiring the person swapping in and the person swapping out to be online.

## Goals and Assumptions
The assumption is very simple: There is a set of `N` participants whose public keys are known.


The goal is essentially to simulate futures contract trading on Bitcoin; at the beginning, the DLC will be between two predetermined participants (WLOG say participants `0` and `1`). After that, the futures contract can be constantly traded between participants by one person swapping out and another swapping in, without interaction of the person staying in the contract. It is even possible to create cycles where we come back to the original two participants; for example, the following interaction is possible:

1. Persons [0, 1] are the original two participants.

2. Person 0 swaps out and Person 2 swaps in (In exchange for some amount of monetary transfer from Person 2 to Person 0), leading to Persons [1, 2] being the new participants.

3. Person 1 swaps out and Person 0 swaps in (In exchange for some amount of monetary transfer from Person 0 to Person 1), leading to Persons [0, 2] being the new participants.

4. Person 2 swaps out and Person 1 swaps in (In exchange for some amount of monetary transfer from Person 1 to Person 2), leading to Persons [0, 1] being the new participants. Notice that they were also the original participants in the contract.  

It is important to note that the contract does not have to end with the original two participants having control of the contract; in fact, in the above, if we just ended the process after step 3 where Persons [0, 2] have control over the contract, they would still be able to settle and get their money out.

Another important detail is that the contract must have some type of expiration date (like a futures contract does) so that the DLC can be settled at some point.


## Signing
We need to do some signing initially (just like regular DLCs require us to sign CETs before we put the funding transaction on chain). We have to sign two types of transactions here:

### Transformation Transactions

For this part, we use `SIGHASH_ANYPREVOUT | ANYONECANPAY | SINGLE` to sign off on the spending condition and amount of the 0th input and the entire 0th output.


For every pairwise distinct, unordered triple of people `(i, j, k)`, person `i` must sign the following transaction using `SIGHASH_ANYPREVOUT | ANYONECANPAY | SINGLE`:

---------------------------------------------------------------

Input 0 script pubKey (well it's the script pubKey of the previous output to be more precise..): (Person `i & j` multi-sig)

Input 0 amount: Same as funding TX amount

---------------------------------------------------------------

Output 0 script pubKey: (Person `i & k` multi-sig)

Output 0 amount: Same as funding TX amount

---------------------------------------------------------------

The total number of transactions created here is `O(N^3)` (where `N` is the number of people).

### CETs

For every pairwise distinct, unordered pair of people `(i, j)` and every oracle outcome, person `i` must sign the following transaction using `SIGHASH_ANYPREVOUT`:

---------------------------------------------------------------

Input 0 script pubKey: (Person `i & j` multi-sig)

Input 0 amount: Same as funding TX amount

---------------------------------------------------------------

Output 0: Pay to Person `i`'s PKH (amount based on oracle outcome)

---------------------------------------------------------------

Output 1: Pay to `(Person j + Oracle) || (Person i & OP_CLTV)` (amount based on oracle outcome)

---------------------------------------------------------------

A minor detail here is that these CETs should have timelocks on them so they are only valid after the expiration date (this prevents someone from just putting a CET on chain if they are sure of the oracle outcome and preventing future transformation transactions).

The total number of transactions created here is `O(N^2 * O)` (where `N` is the number of people and `O` is the number of outcomes).

## Put Funding TX on chain

The next step is to create a single initial DLC funding transaction between two arbitrary parties (WLOG let's say Persons `0` and `1`) and put it on chain.

## Creating Transformation Transactions

Let's say Persons `i` and `j` are currently in the contract (which implies a multisig between two exists at the moment). Let's say that person `j` wants to swap out and person `k` wants to swap in; in this case, both person `j` and `k` need to be online and interact, but person `i` does not need to be there. Person `j` and `k` will construct the following transaction:

---------------------------------------------------------------

Input 0 script pubKey: (Person `i & j` multi-sig)

Input 0 amount: Same as funding TX amount

---------------------------------------------------------------

Input 1: Any UTXO spendable by Person `k`

---------------------------------------------------------------

Output 0 script pubKey: (Person `i & k` multi-sig)

Output 0 amount: Same as funding TX amount

---------------------------------------------------------------

Output 1: Some agreed upon amount is sent to Person `j`'s PKH.

---------------------------------------------------------------


Person `k` will then insert in Person `i`'s relevant Transformation Transaction signature (during the signing phase, Person `i` already created and published this signature) and sign themselves. They will then send the signed transaction to Person `j`, who can then sign and send the transaction into the mempool.

Any number of these transformation transactions can be put on chain, one after another. As a result, ownership of the contract can constantly change.

## Final CET

Once the final expiration time is reached, the oracle publishes the outcome and a CET can be put on chain by either party. WLOG assume that persons `i` and `j` are currently in the contract. Let's say that person `j` wants to be the one to publish the final settlement transaction. Person `j` will create and sign the following transaction:

---------------------------------------------------------------

Input 0 script pubKey: (Person `i & j` multi-sig)

Input 0 amount: Same as funding TX amount

---------------------------------------------------------------

Output 0: Pay to Person `i`'s PKH (amount based on oracle outcome)

Output 1: Pay to `(Person j + Oracle) || (Person i & OP_CLTV)` (amount based on oracle outcome)

---------------------------------------------------------------

They will use Person `i`'s signature which already exists from the signing phase to complete the transaction. They will then send this to the mempool.

## Security Considerations


There exist at least two interesting security considerations:

1. Say Person `i` and `j` are currently in the contract, and `k` wants to swap in for `j`. Person `k` signs a transformation transaction and sends it to `j`. Person `j` can now wait a while before they send the transaction into the mempool (to see if it is advantageous to do so). Person `k` has the option to respond to this by spending the UTXO they are using as an input,  but it could become some type of priority gas auction if they try to do this simultaneously.

2. Say the expiration time has passed, and someone wants to be a sore loser. They can keep sending transformation transactions to prevent a CET from being put on chain. The deterrent here is that they literally have to do this every single block and they lose the transaction fee, which adds up to pretty significant sums of money. This only delays the inevitable, however, because at some point the CET will be put on chain and everything will be settled.

Would be interested if anyone has thoughts on this.