path: root/47/75e471db1e94db7e15d1f6d3ba3da9db519c48

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id E1FEFC0865
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Jun 2020 05:43:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id D173C203DC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Jun 2020 05:43:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id HM5owBPCkPDi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Jun 2020 05:43:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by silver.osuosl.org (Postfix) with ESMTPS id 57D13203DA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Jun 2020 05:43:40 +0000 (UTC)
Date: Fri, 12 Jun 2020 05:43:29 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1591940617;
 bh=fWuegturgFxG6g1nZL7h1s3F4J7TKgz/xRGJiYMXOkU=;
 h=Date:To:From:Reply-To:Subject:From;
 b=MzsqF9VTuJloHHmhsMH8TU3pIwK7bVlegnEHzZhAcPs/AKCA3QsZyJI8u43mf/1jl
 I9iAvucOyNlDWTADA89ZDVgpSxssI4wE1wlxCslbQPPJqAFSuQWa7D86f/2YMD6VYU
 v6nZhOqHjHNJLgJCGR9e16Y2yUhTLRRhjMgSDgPg=
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <D2DWwPP0JpNM3V2tbq_dUMZl4W24rsE6Evn265S6KEwe-_vyc9KNy8gHegbFzoM2xr72d_9VwsXHe3TSYmXpXM7ytkN5zIqZnskXL-Ew_xQ=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] WabiSabi Inside Batched CoinSwap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2020 05:43:44 -0000

Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 SRSL=
Y.

While [WabiSabi](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20=
20-June/017969.html) is planned for some kind of CoinJoin operation, a limi=
tation is that the use of CoinJoin creates a transaction where the inputs a=
re 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 indep=
endent outputs it owns, acquired from previous clients.
Then the outputs would, onchain, be linked to previous clients of the serve=
r instead of the current clients.
This is precisely the issue that CoinSwap, and the new swap scheme [Succinc=
t Atomic Swaps](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/202=
0-May/017846.html), can be used to solve.
By using [Batched CoinSwap](https://lists.linuxfoundation.org/pipermail/bit=
coin-dev/2020-June/017967.html), makers can act as WabiSabi servers, and ba=
tched 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 l=
east by the maker, to inputs given to the maker, which is precisely the inf=
ormation 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 sta=
ndard 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

    s =3D 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 sam=
e validation as for Schnorr signatures.

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

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

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

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

WabiSabi
=3D=3D=3D=3D=3D=3D=3D=3D

WabiSabi replaces blind signatures with credentials.
The primary advantage of credentials is that credentials can include a homo=
morphic 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 credentia=
ls they received from the server and exchanging them for fresh credentials.
Clients hold multiple credentials at a time, and the server consumes (and d=
estroys) 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 f=
ees 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 inp=
ut credential value plus the onchain input value.
3.  Clients swap credentials with each other to perform payments between th=
emselves, then claim the credentials by asking the server to reissue them.
    * Receiving clients move their amounts among all the credentials they o=
wn (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-va=
lue credential from the sending client, by cooperatively making a consume-r=
eissue 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 ba=
ck 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 expecte=
d (their claimed outputs exist) and ratify the overall transaction.
    * In the CoinJoin case, the overall transaction is ratified by generati=
ng a single transaction that consumes the inputs and generates the output s=
et, then the clients provide signatures to this transaction as ratification=
.

WabiSabi Inside Batched CoinSwap
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

A Batched CoinSwap simply means having multiple takers be serviced in a sin=
gle 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 th=
at Bob saved her life and her entire kingdom, involving a lot of gunfire, e=
xplosions, evil wizards, pre-asskicking one-liners, and a bomb that is defu=
sed 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 Bo=
b.
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 transa=
ction.

Macky operates as a WabiSabi server, and Alice, Bob, and Carol operate as W=
abiSabi clients.
Rather than generate a single CoinJoin transaction, they generate a CoinSwa=
p 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 fr=
om Macky.
They then register inputs in the WabiSabi protocol, and also additionally p=
erform this sub-ritual in order to "lock in" the input registration:

* Alice (resp. Bob or Carol) creates (but does *not* sign) a funding transa=
ction 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 transfer=
s 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 M=
uSig(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 `nLockTim=
e` 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 onchai=
n 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 Wabi=
Sabi-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 co=
ins of Alice, Bob should avoid the altar until the entire WabiSabi-in-Batch=
ed-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 n=
ew 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 output=
s to "Bobby", "Carolina", and a change output to Macky.
This is done by presenting a transaction spending the Macky funding transac=
tion 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 transacti=
on 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 (output=
s + fees =3D 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 pa=
yout transaction all the way to R exchange.
* Then Alice, Bob, and Carol compute and broadcast their MuSig signature sh=
ares 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 t=
akers, broadcasts s[M] * G.

At this point, the participants now turn their attention to the inputs to t=
he 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 ou=
tput to Macky.
* Alice and Macky complete the MuSig signing ritual for the Macky claim tra=
nsaction 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, whos=
e 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 tra=
nsaction, and also complete all the claim transaction it needs.
If any of Alice, Bob, or Carol do not provide the partial adaptor signature=
s for any of the incoming inputs, Macky never broadcasts s[M] and the CoinS=
wap and all WabiSabi internal value transfers revert.

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

It would be possible to hand over private keys for the Alice, Bob, and Caro=
l 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 cli=
ents it wants to serve.

Comparison to WabiSabi Inside CoinJoin
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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 payou=
t 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 sockpup=
pets 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 ho=
w 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 positi=
ves).

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