Message-ID: <fd3a433b-9e95-194e-bf91-47b61f981d1b@towardsliberty.com>
Date: Wed, 30 Mar 2022 13:57:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Content-Language: en-US
From: Max Hillebrand <max@towardsliberty.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [bitcoin-dev] WabiSabi P2EP / Wormhole 2.0
Precedence: list

Hello List,

tl;dr, users of WabiSabi coinjoin can pay arbitrary amounts of bitcoin, 
so that the sender does not learn the address/output of the receiver, 
and the receiver does not learn the input of the sender. This improves 
the previously proposed 'Wormhole' for Chaumian blind signature 
coinjoin, by allowing arbitrary amount payments and by reducing block 
space for change decomposition. 
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg08622.html


Assume that the sender and the receiver are both online and have a 
direct communication channel [P2EP]. The sender registers an input 
[let's say 1 btc value] with a third-party WabiSabi coordinator. In 
exchange, the sender receives a keyed-verified-anonymous-credential. The 
sender can present the 1 btc credential, and request a reissuance of two 
new credentials worth for example 0.3 btc and 0.7 btc. Since Pedersen 
commitments are the attributes of the KVAC, the coordinator does not 
learn any of those amounts.

Next, the sender gives the receiver through the P2EP connection the KVAC 
corresponding to the amount that is due pay. Now the receiver presents 
this credential to the coordinator, and requests a reissuance, which can 
again be split up into two credentials, for example 0.1 and 0.2. At this 
point, the sender can no longer present the old credential, the 
coordinator ensures double spending protection.

Later during output registration, the sender registers with the 
coordinator his "payment change outputs", which again can be decomposed 
client side into multiple outputs, let's say 0.5 and 0.2. Likewise, the 
receiver presents his KVACs, and registers his desired output addresses 
directly with the coordinator.

After output registration, the coordinator aggregates the PSBT with all 
registered inputs and outputs, and presents the unsigned coinjoin 
transaction to all Alices [Tor identities who registered inputs]. Since 
the sender does not know what the receivers output address is, he has to 
ask the receiver through the P2EP connection if this coinjoin is good. 
If response is ACK, then the sender signs for his inputs and registers 
the signatures with the coordinator.

If all inputs sign, we have a successful coinjoin, which includes a 
payment, where the sender never learns the address of the receiver, and 
the receiver never learns the inputs or change outputs of the sender. 
The coordinator can not differentiate users who make self-spends from 
those who do payments, this is entirely client side.


Of course the sender still knows the amount of bitcoin of the credential 
that he passed on to the receiver [the invoiced payment amount]. 
However, similar to PayJoin, the receiver can likewise register inputs 
with the coordinator in the same round. Unlike PayJoin, there are many 
other inputs who do not belong to sender or receiver, which provides the 
desired anonymity set. Such a receiver will have the KVAC originated 
from his own input[s], as well as the KVAC that the sender gave him. Two 
KVACs can be reissued to one, thus anonymous consolidation of inputs + 
payment amount is possible. Since neither the coordinator, nor the 
sender, know the input[s] of the receiver, the final amount on-chain 
[even if only one receiver output is created] does not correspond to the 
payment amount, thus the sender can not identify the output of the 
receiver based on amounts.


A blinded coinjoin coordinator is a PSBT whiteboard, where users 
purchase eCash tokens by registering inputs, and users spend eCash 
tokens in order to register outputs. Users can self-spend the eCash to 
increase anonymity set of those access rights. However, nothing prevents 
the user to make an actual eCash "payment" to someone else, effectively 
abdicating the right to register outputs. If [and only if] the final 
coinjoin has sufficient number of inputs and outputs to provide 
effective blockchain ambiguity, then the resulting payment has 
breathtaking privacy guarantees.


Skol
Max Hillebrand