[bitcoin-dev] WabiSabi Inside Batched CoinSwap

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Introduction
============

THIS ENTIRE PROTOCOL IS NOVEL CRYPTO AND HAS NO PROOF THAT IT IS SECURE AND PRIVATE AND WHY WOULD YOU TRUST SOME RANDOM PSEUDONYM ON THE INTERNET SRSLY.

While [WabiSabi](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017969.html) is planned for some kind of CoinJoin operation, a limitation is that the use of CoinJoin creates a transaction where the inputs are known to be linked to the outputs, as the generated transaction directly consumes the inputs.

It would be better if the server in the WabiSabi created outputs from independent outputs it owns, acquired from previous clients.
Then the outputs would, onchain, be linked to previous clients of the server instead of the current clients.
This is precisely the issue that CoinSwap, and the new swap scheme [Succinct Atomic Swaps](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017846.html), can be used to solve.
By using [Batched CoinSwap](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017967.html), makers can act as WabiSabi servers, and batched takers can act as WabiSabi clients.

Of course, WabiSabi has the advantage that payments between the clients are obscured from the server.
But a naive CoinSwap requires that outputs from the maker be linkable, at least by the maker, to inputs given to the maker, which is precisely the information that WabiSabi seeks to hide from the server.

However, by instead using [Signature Selling](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002077.html) in combination with standard Scriptless Script adaptor signatures, it is possible to arrange for a CoinSwap to occur without the make being able to link outputs to inputs.

Signature Selling
=================

The final output of the Schnorr signing process is a pair (R, s) for a pubkey A = a * G and ephemeral nonce R = r * G, where:

    s = r + h(P | R | m) * a

Now, instead of the pair (R, s), the signer can provide (R, s * G).
The receiver of (R, s * G) can validate that s * G is correct using the same validation as for Schnorr signatures.

    s * G = R + h(P | R | m) * A

The receiver of (R, s * G) can then offer a standard Scriptless Script adaptor signature, which when completed, lets them learn s.
The receiver may incentivize this by having the completed signature authorize a transaction to the sender of the original (R, s * G), so that the completed signature atomically gives the receiver the correct signature.

This can be used as a basis for atomic CoinSwap, and which we will use in this proposal.

Note that even in a MuSig case, it is possible for a participant to sell its share of the final signature, after the R exchange phase in MuSig.

WabiSabi
========

WabiSabi replaces blind signatures with credentials.
The primary advantage of credentials is that credentials can include a homomorphic value.
We use this homomorphic value to represent a blinded amount.

WabiSabi has a single server that issues credentials, and multiple clients that the server serves.
Clients can exchange value by swapping credentials, then claiming credentials they received from the server and exchanging them for fresh credentials.
Clients hold multiple credentials at a time, and the server consumes (and destroys) a set of credentials and outputs another set of fresh credentials, ensuring that the output value is the same as the input value (minus any fees the server wants to charge for the operation).

From a high enough vantage point, the WabiSabi process is:

1.  Server issues 0-valued credentials to all clients.
2.  Clients put in money into the server by providing onchain inputs to the server plus their existing credentials, getting credentials with their input credential value plus the onchain input value.
3.  Clients swap credentials with each other to perform payments between themselves, then claim the credentials by asking the server to reissue them.
    * Receiving clients move their amounts among all the credentials they own (via server consume-reissue credential operations) so as to make one of their multiple credentials into a 0-value credential.
    * Sending clients move their amounts among all the credentials they own so that one of their multiple credentials has the sent value.
    * The receiving client exchanges its 0-value credential for the sent-value credential from the sending client, by cooperatively making a consume-reissue operation with the server.
4.  Clients then claim the value in their credentials by providing pubkeys to pay to, and amount, to the server, plus existing credentials, getting back credentials whose total value is minus the onchain output value.
5.  The server generates the final output set.
6.  The clients check that the final output set is indeed what they expected (their claimed outputs exist) and ratify the overall transaction.
    * In the CoinJoin case, the overall transaction is ratified by generating a single transaction that consumes the inputs and generates the output set, then the clients provide signatures to this transaction as ratification.

WabiSabi Inside Batched CoinSwap
================================

A Batched CoinSwap simply means having multiple takers be serviced in a single transaction by a single maker.

Suppose Alice, Bob, and Carol are takers, and Macky is the maker.

Now suppose that Alice is secretly the princess of a magical kingdom and that Bob saved her life and her entire kingdom, involving a lot of gunfire, explosions, evil wizards, pre-asskicking one-liners, and a bomb that is defused by Bob with just 1 second left on its timer.
Alice now owes a life debt to Bob and agrees to give all her bitcoins to Bob.
However, because the existence of magic is a secret, they do not want Carol, Macky, or the entire Bitcoin world to know about this Alice-to-Bob transaction.

Macky operates as a WabiSabi server, and Alice, Bob, and Carol operate as WabiSabi clients.
Rather than generate a single CoinJoin transaction, they generate a CoinSwap operation.

First, they all agree on future blockheights L1 and L2, where L1 < L2.

Then Alice, Bob, and Carol get the starting 0-value WabiSabi credentials from Macky.
They then register inputs in the WabiSabi protocol, and also additionally perform this sub-ritual in order to "lock in" the input registration:

* Alice (resp. Bob or Carol) creates (but does *not* sign) a funding transaction from Alice coins to MuSig(Alice, Macky).
* Alice and Macky create a backout transaction, with `nLockTime` at L2, and complete the plain MuSig signing ritual.
* Alice broadcasts the original funding transaction.

Macky need not wait for the funding tx to confirm; at a later stage, if it is not confirmed, Macky can cancel the entire ritual and all value transfers within it.

Then, before transitioning to the WabiSabi output registration stage, Macky performs the following ritual with Alice, Bob, and Carol.

* Macky creates (but does *not* sign) a funding transaction from Macky to MuSig(Alice, Bob, Carol, Macky).
  * The value must be greater than or equal to the total input values; but note that Alice, Bob, and Carol need not check this, as it is automatically implied by the later output ratification phase.
* Alice, Bob, Carol, and Macky create a backout transaction, with `nLockTime` at L1 (L1 < L2), and complete the composable MuSig signing ritual.
* Macky broadcasts the original funding transaction.

Again nobody needs to wait for the Macky funding transaction to come onchain at this point.

Alice can then send Bob all her money by use of WabiSabi inter-client value transfers.
Bob should not consider this value transfer as "real" until the entire WabiSabi-in-Batched-CoinSwap ritual is complete, by the way: so for example if Bob is required to marry princess Alice contingent on getting all of the coins of Alice, Bob should avoid the altar until the entire WabiSabi-in-Batched-CoinSwap ritual completes.

Then, output registration can begin.
In output registration, Bob and Carol take on new identities, as Bobby and Carolina, respectively.
Alice, having no funds inside the WabiSabi to reclaim, has no need of the new identity.
"Bobby" claims an output, to be sent to "Bobby", as does "Carolina".

At this point, Macky checks the Alice, Bob, and Carol funding transactions were confirmed deeply.
If not, Macky aborts the CoinSwap and waits until it can reclaim its funds.

Then, Macky enters the output ratification phase.
Macky publishes all the outputs registered, which should include the outputs to "Bobby", "Carolina", and a change output to Macky.
This is done by presenting a transaction spending the Macky funding transaction output with MuSig(Alice, Bob, Carol, Macky) and outputting to "Bobby", "Carolina", and Macky change.

At this point, Alice, Bob, and Carol check that the Macky funding transaction was confirmed deeply.
If not, Alice, Bob, and Carol aborts the CoinSwap and waits until they can reclaim the funds.

Then, Alice, having no outputs, approves the payout transaction.
Bob checks that the "Bobby" output exists and is the correct value.
Carol checks the "Carolina" output exists and is the correct value.
They also check that the payout transaction would actually be valid (outputs + fees = input, current `nLockTime`, etc.).

If one of the takers thinks the server misbehaved, they can just refuse to ratify the output.

Alice, Bob, and Carol can now cooperatively ratify the outputs produced by Macky.
This is done in a long ritual.

* First, Alice, Bob, Carol, and Macky complete the MuSig signing for the payout transaction all the way to R exchange.
* Then Alice, Bob, and Carol compute and broadcast their MuSig signature shares s[A], s[B], and s[C] to each other and to Macky.
* Macky then computes its share s[M], but rather than broadcast it to the takers, broadcasts s[M] * G.

At this point, the participants now turn their attention to the inputs to the mix.

* Now, Alice (resp. Bob or Carol) knows s[A], s[B], s[C], and s[M] * G for the payout transaction.
* Alice and Macky create a claim transaction spending from Alice funding output to Macky.
* Alice and Macky complete the MuSig signing ritual for the Macky claim transaction up to R exchange.
* Macky gives its share of the Macky claim transaction signature to Alice.
* Alice provides an adaptor signature for the Macky claim transaction, whose completion would let Alice learn s[M] for the payout transaction.

After Macky gets partial adaptor signatures from Alice, Bob, and Carol, it can then broadcast s[M] to Alice, Bob, and Carol, completing the payout transaction, and also complete all the claim transaction it needs.
If any of Alice, Bob, or Carol do not provide the partial adaptor signatures for any of the incoming inputs, Macky never broadcasts s[M] and the CoinSwap and all WabiSabi internal value transfers revert.

Private Key Handover
--------------------

It would be possible to hand over private keys for the Alice, Bob, and Carol funding transaction to Macky, and use a kickoff transaction followed by a `nSequence`-timelocked transactions for backing out.
This reduces the onchain space needed when Macky has another new set of clients it wants to serve.

Comparison to WabiSabi Inside CoinJoin
======================================

The above CoinSwap ritual requires more transactions onchain, and thus more expense.

However, it does buy better privacy.

* Carol never learns the inputs of Alice and Bob, and only knows that there are up to 2 other participants in the mix.
  * Carol only ever signs its own funding transaction output, and the payout transaction; the payout transaction does not reveal the inputs that other participants put into the mix.
  * For all Carol knows, the two other participants in the mix were sockpuppets of Macky, or were really just one participant using a sockpuppet.
* Bob never learns the input of Alice.
  * Bob knows how much Alice gave to Bob and that Alice gave her all to Bob, so in a CoinJoin could have scanned for CoinJoin inputs that sum up to how much Alice gave to Bob.
  * With CoinSwap, Bob has to scan recent blocks, which hopefully have much larger input sets and require more effort (and hopefully more false positives).

This is because knowledge of the *other* inputs to the mix is never revealed in a batched CoinSwap, whereas they would be revealed in a CoinJoin.
All that participants learn is the inputs from *previous* takers that the maker served in the past.