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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to