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 gen
