From: Max Hillebrand <max@towardsliberty.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] WabiSabi P2EP / Wormhole 2.0
Date: Wed, 30 Mar 2022 13:57:47 +0200 [thread overview]
Message-ID: <fd3a433b-9e95-194e-bf91-47b61f981d1b@towardsliberty.com> (raw)
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
reply other threads:[~2022-03-30 11:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd3a433b-9e95-194e-bf91-47b61f981d1b@towardsliberty.com \
--to=max@towardsliberty.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox