"On chain contracting" is of course a very generic term; it applies to multisignature, coinjoin, coinswap
or other exotic transactions that involve more than one party in one transaction (coinjoin, multisig)
or multiple transactions (swaps with atomic-via-secret).

Here we're going to focus on a broader model that may allow more complex setups,
with a focus on how they may apply to gaining privacy, although this model may well be useful in other ways too.

### General concept

Segwit enables pre-signing of not just individual, but chains of transactions.

Each txid is now only dependent on transaction semantics, not on signatures.

To create a co-agreed contractual arrangement requires an initial phase of transferring ownership of coins
into a shared control area; this will be one or more utxo outpoints under 2 of 2 or more generally N of N parties.

To make this trustless it's required there be a backout mechanism or "refund". This is because if either
party has no refund clause in advance, the other party(ies) can hold up the funds deposited to said "shared control area", creating a deadlock and thus reverting to a MAD game theory negotiation.

This refund clause can take more than one form, the obvious cases being either (a) create separate refund transactions with a locktime to give a time period of shared ownership, or (b) separate conditional paths in Script using CLTV or CSV to achieve the same purpose.

The latter, (b), is more simple, arguably, but the former is usually preferred if the focus is on privacy (so the scriptPubKey funded into does not have custom redemption paths; *but* see MAST).

Thus for the rest of this document, in which we focus on potential privacy applications of contracting on-chain, we will assume the use of (b) style refunds.

Based on this refund concept, along with the idea of pre-signing being safe in a segwit-enabled chain as we have today,
we thus envisage a picture something like this (we work only with 2 party case; N party can be considered later):

```
                            ---> Refund locktime: N+M blocks -> pay out to A,B
                            |
A 1btc --->                 |
              F (2,2,A,B) ---
B 1btc --->                 |
                            |
                            -->[Working area]

```

 In human terms, you can envisage that: Alice and Bob would like to start to negotiate a set of conditional contracts
 about what happens to their money. Then they go through these steps:

 1. Before committing to anything, they first sign a "I get my money back untouched if we can't completely agree to terms, after a delay of N+M blocks" contract - the refund.
 2. With this in place, they commit funds by transferring into the shared account, here called "F" (for "funding transaction") and wait N blocks for confirmation.
 3. Now both sides have committed funds ("skin in the game" :)), during the M block period they have no ability to renege by double-spending F's outpoint(s).
 4. So now they are both safe to start work on what's called above the 'working area'. In this area they can create a whole graph of transactions, **each** of which depends (along its ancestor path) on the original F outpoint, and **each** of which requires both signers agreement.
 5. Once they have created the graph of transactions which is to both of their liking, they can sign all of these transactions, and pass signatures to the counterparty, with the crucial condition: the first transaction in the working area spending *out* of F must be signed **last**.
 6. If 5 is carried out successfully, it is guaranteed that the entire set of transactions in the working area will be broadcast iff at least one of the parties actually wants to broadcast them.

 Shortly we'll delve into some details that are glossed over in the above 6 step summary. But before that, let's make some
 high level comments about this:

#### Comparison with Lightning concept

Lightning leverages the idea of pre-signing sets of contracts in a (small) transaction graph, but it is focused on a much cleverer and more powerful trick added on to this: the ability to update a set of contracts by invalidating a previous set of contracts (see concepts like "breach remedy" and the sharing of a secret to invalidate a prior contract set).

Rather whimsically I propose to call Lightning (or any uni- or bi-directional channel idea really) "vertical contracting" (imagine new contracts "overlaying" previous; although I guess literally ripping up old contracts is a more accurate analogy), while what is being discussed here is more like "horizontal contracting"; preparing whole chains or trees of transactions, *all* of which will go on-chain. There is no updating here (at least, not in this proposal), there is just a primary backout of cancelling *all* contracts and reverting to a refund.

#### Advantages over contracting on chain without pre-signing

A good practical example of on-chain contracting today is Joinmarket, in which multiple parties engage in single-transaction coinjoin contracts. A user may often choose to do what is known as the "tumbler algorithm", running a whole set of coinjoins over a long period by finding counterparties to do the joins in a specifically arranged sequence to maximize the privacy effect. One of the big disadvantages of this is the long time frame interactivity (having to exchange messages with external counterparties in bursts, separated sometimes by several hours, over days in some cases). This makes things harder in terms of network connection management, running hot wallets etc.

So while the ability to do all the negotiation immediately, upfront is a nice practicality win, it's not what's really important here: what's really important is that
*because the trustlessness is now spread out over an entire chain or tree of transactions, there is no problem with
swapping control of coins in individual transactions*. This can invalidate assumptions that an external observer makes
about the *meaning* of transactions on chain (which is why I think it can be important for privacy applications,
although I don't assume there are no other things you can do with it).

While there is no direct drop-in replacement for tumbler in this proposal (that's going too far), in broad outline we can imagine the great advantage of being able to make a whole set of negotiations all at the start, including signing operations, so that direct over the wire interactivity is reduced to a very short time frame.

#### Anonymity set issues

As presented above, parties use a principal 2 of 2 destination for the funding transaction, and (with some possible exceptions) 2 of 2 shared control points as inputs to each transaction in the graph. In general terms this is a watermarking effect on these transactions. But consider these points:

1. In a Schnorr enabled world, this watermarking disappears.
2. In the absence of Schnorr and of any efforts to change this, it still isn't that bad:
 a. You still have the anonymity set of all 2 of 2 transactions
 b. You can improve this to general 2/2 2/3 (the majority of multisig usage) since you can use fake 3rd keys.
 c. If thinking about coinjoins in particular, they are already entirely identifiable (except very unusual niche coinjoin usages).

It's worth thinking carefully about other watermarking issues, though. For timing correlation issues, we have:

1. Voluntary cooperation on broadcast times (not strong, but "defection" here is less likely, still a big issue).
2. Locktimes, but this watermarks (weakly).
3. In some cases immediate multiple broadcasts aren't that rare, so it may be less of an issue.

#### The set of possible privacy use-cases

These are chains of connected transactions (or trees, but always with F at the root); so, it stands aside from ideas like "Coinswap" where there is more than one transaction flow involved. However, that doesn't mean that an atomic swap type construction couldn't be somehow blended into this model; but we defer that idea for another time.

It fits nicely along with coinjoin-like ideas though. An example of using this to create multiple coinjoin transactions is shown in the next section ("Concrete example").

Let's remember the core concept of coinjoin: the Nakamoto/Meiklejohn assumption/heuristic states that "multiple inputs in one transaction implies common ownership", which is false in coinjoins. Usually coinjoins are made acceptable to participants by allowing all parties to achieve net zero transfer between ins and outs (in Joinmarket that is tweaked but not by much), which gives extra ammunition to blockchain analyst: perform subset sum analysis on the (ins, outs) sets, which re-links ins and outs up to the non-equal amounts (but no further). See "coinjoin sudoku".

With this new model, although, as presented, it's much more restricted than a full network of coinjoin transactions, that assumption is not just unsafe, but very likely flat out wrong; there is no requirement for individual transactions in the "working area" to preserve the balance of individual participants, because we've spread the trustlessness of a single transaction to the whole transaction graph in the working area.

### Concrete example - a multisig-based coinjoin chain.

This example case is intended to flesh out some details that may be unclear in the high-level description above.

As before we start with Alice and Bob, 2 parties, they have established funds into F. In this case,they each contribute 1 btc and F has a single 2 btc output. Here "22AB_n" means the nth created 2 of 2 shared control destination for Alice and Bob.

```
    ---> refund, locktime-d, destns: Alice 1btc, Bob 1btc.
    |
    |
 (F) --> TX1(out_0: Alice 0.8 btc, out_1: 22AB_1, 0.8 btc, out_2: 22AB_2, 0.4 btc)
            --> TX2(outs: out_0: Bob, 0.2 btc, Alice, 0.2 btc, out_2: 22AB_3: 0.8btc)
                   --> TX3(outs: out_0: Bob, 0.6 btc, out_1: Bob, 0.2 btc)
 ```

(The `-->` here imply that the inputs of the succeeding transaction are exactly the outputs of the previous one.)

The level of obfuscation achieved by this is not very strong (mainly because there are only 2 parties), but it does deliver the basic functionality of coinjoin: ownership of TX1 out_0 and TX2 outs 0 and 1 are obscured through the use of equal sized outputs. And it has the virtue of being ultra simple and so easy to explain; we could make far more complex examples including not a single branch, but a tree.

 Obviously neither side wants the sequence to only partially complete. If they can blackmail each other to finish the sequence it's bad enough; it's even worse if one side has more at stake than the other (as Bob would if only TX1 were broadcast). So the scheme specifically prevents this.

 The two sides have calculated the unsigned serialization of each of these transactions in advance;
 once F is under N blocks they can follow this sequence:

 * Alice and Bob both sign both inputs to TX3 and transfer sigs to each other; this can happen in any order.
 * Both sides verify the other sides' signatures.
 * The same as above is repeated for TX2.
 * Both Bob and Alice sign TX1 using F's single outpoint as input
 * Both Bob and Alice pass their TX1 sigs to each other (in either order)
 * Both Bob and Alice verify that TX1 is validly signed.
 * Now either Bob or Alice can choose to broadcast all transactions TX1, TX2, TX3 (with delays if they choose).

 If any of the above steps fail (except the last one), they must fall back to the refund transaction after N+M blocks.

What we see from this example:

* For trustlessness, it's critical that TX1 (the spend out of F) is signed cooperatively, and signed *last*.
 But it's also necessary that **all** inputs to each transaction are under joint control. **The reason for this is: if, say, TX2 had an input from Alice only, it could be pre-signed, but Alice could spend that utxo out from under the process, thus breaking the trustless chain.**
* Outputs, of course, have no such restriction; we can use this to "peel off" amounts to Alice or Bob or a third party during the sequence of transactions.
* Notice that the order of signing of TX2 and TX3 doesn't matter. It just matters that they're *all* verified correct before moving to TX1.