Re: [bitcoin-dev] WabiSabi Inside Batched CoinSwap

2020-06-12 Thread ZmnSCPxj via bitcoin-dev
Good morning list,

> -   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.

Sorry, the taker funding transactions should have the nearer locktime L1, and 
the maker funding transctions should be the one with the later locktime L2.
This forces Macky to claim the incoming funds earlier, and claiming any of them 
unlocks the outgoing payout transaction.

bitcoin-dev mailing list

[bitcoin-dev] WabiSabi Inside Batched CoinSwap

2020-06-11 Thread ZmnSCPxj via bitcoin-dev


 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 
 can be used to solve.
By using [Batched 
 makers can act as WabiSabi servers, and batched takers can act as WabiSabi 

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 
 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 

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 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