Reverse CoinJoins

REVERSE COINJOINS

I. Wasabi Background.

Right now Wasabi works like this:
Peers get together, everyone registers inputs and a blinded output, got a blinded signature from the coordinator, then register their outputs with unblinded signatures, finally the coordinator creates the coinjoin and gives it out for peers for signing.

This means if a user wants to mix 18BTC, it needs to do 18 rounds of this, assuming 1BTC denomination.

As of writing this, Wasabi is releasing a basic unequal input mixing algorithm[0], which changes the protocol in a way that the server gives out multiple blinded outputs for multiple blinded denomination. All of these denominations are multiplications of the base denomination. Assuming 1BTC base denomination, it'd be 1, 2, 4, 8, 16, 32, ...
Finally at output registration a user register multiple outputs through different Tor identities.

This kind of mixing is done always back to the user and this paper is intended to describe an extension to the protocol above to enable mixing to someone else.

II. Reverse CoinJoins Extension

The protocol would change in a way that, at output registration, the user would not only provide an unblinded signature and an output, but the user would also provide a value as to how much money he wants to send to the output he provided, and a change output as to where the change would go.
Furthermore the user could provide multiple unblinded signatures in this output request, thus the user could specify larger amounts as for the value. For this to not break anonymity, the user should only provide larger values if he registered base-denomination coins. This however does not have to be enforced on the server side, rather the client software could handle it.

For example the client software would let the user to register multiple 0.1BTC outputs into the mix. Since about 30-40% of the mix are such remixes today, the user could rightfully predict that there will be sufficient amount of these kind of outputs registered to the coinjoin.

The insight here is that in this case the user is mixing not with his equal outputs, but with his equal inputs! Thus the name reverse coinjoins.

III. P2EP[1] - Sender Receiver Extension (= Reverse CoinJoin - PayJoin Mode).

If the sender and the receiver both participates in the coinjoin, they may as well register the same blinded output (the receiver's) thus the exact same benefits can be achieved as with PayJoin[2], except that the steganographic nature of this scheme does not apply to the whole blockchain, only to coinjoin transactions (exponentially kicks off the possible interpretations of all the coinjoins, even if nobody used it!)
Note that, it needs no modification to the coordinator or to the communication between the client and the coordinator. The only thing needs to be done is for the receiver to send a Bitcoin address to the sender, who's going to use CoinJoin to send to the address - and then participate in the next round with the same address!

Drawbacks to PayJoin (P2EP - Sender-Receiver)
-1> It does not help with the anonymity of the whole Bitcoin network.

Additional Benefits to PayJoin (P2EP - Sender-Receiver)
-1> It multiplies a coinjoin's possible interpretations.
-2> It does not need an additional connection to be established between sender and receiver, nor additional information transferred than the bitcoin address and the intent of mixing, since the coinjoin as it happens normally is that connection.
-3> Unlike in PayJoin, the sender can rarely identify which input the receiver possessed.
-4> The receiver can reuse its address and make multiple senders to pay for him the same time, which at this point it's hard to imagine how many possible interpretations it'd result for the coinjoin transaction.

Trustlesness.
In order to sing, Sender must check if the output has more money on it than he intended to send.
In order to sign, Receiver must check if the output has more money on it than he mixed + intend to receive.

* Note, that in order for this to work the user must not register his multiple outputs in one go, but rather one by one, it just registers the money to the same address, so the server should not be able to decide if it was registered by the sender or the receiver.

References.
[0] Wasabi - Basic Unequal Amount Mixing: https://medium.com/@nopara73/upcoming-wasabi-wallet-hard-fork-609f271d9c41
[1] Pay-To-EndPoint: https://medium.com/@nopara73/pay-to-endpoint-56eb05d3cac6
[2] PayJoin: https://joinmarket.me/blog/blog/payjoin/