1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
Return-Path: <max@towardsliberty.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3AE7DC0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Mar 2022 11:58:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 29CD1843B8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Mar 2022 11:58:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.351
X-Spam-Level:
X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=neutral
reason="invalid (public key: not available)"
header.d=towardsliberty.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id L3pN-qy5yKU8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Mar 2022 11:58:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from subsea-epitome.host4coins.net (subsea-epitome.host4coins.net
[185.150.162.112])
by smtp1.osuosl.org (Postfix) with ESMTPS id D2668842ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Mar 2022 11:58:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by subsea-epitome.host4coins.net (Postfix) with ESMTP id CBC8E81936
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Mar 2022 11:58:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=
towardsliberty.com; h=content-transfer-encoding:content-type
:content-type:subject:subject:from:from:content-language
:user-agent:mime-version:date:date:message-id; s=default; t=
1648641470; x=1650455871; bh=JWjDeGwIQhXGjS58mNL/Xg8Wx840APlXZLX
p9HuaPmc=; b=fU49lzZvxV8ne7LrPMz9vlImbO9eX28y//oSOnfZYf0aAEmfttP
vTbcFY8hYRSDXK0U93TDf7Msg9xfZouLcKVpbH74LL7EatEqMs/8CPDpDGbJhkvd
gQAutXHQeqsqeJw/937u5qJzVW0pKy/wRs6g7Nnc3SdsjYB9109uqPCs=
X-Virus-Scanned: Debian amavisd-new at subsea-epitome.host4coins.net
Received: from subsea-epitome.host4coins.net ([127.0.0.1])
by localhost (subsea-epitome.host4coins.net [127.0.0.1]) (amavisd-new,
port 10026)
with LMTP id m3CtxXKnIEOw for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Mar 2022 11:57:50 +0000 (UTC)
Received: from [10.137.0.32] (tor-exit-01.darklab.sh [89.58.27.84])
(Authenticated sender: max@towardsliberty.com)
by subsea-epitome.host4coins.net (Postfix) with ESMTPSA id 5245481726
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Mar 2022 11:57:50 +0000 (UTC)
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
X-Mailman-Approved-At: Wed, 30 Mar 2022 13:11:52 +0000
Subject: [bitcoin-dev] WabiSabi P2EP / Wormhole 2.0
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: Wed, 30 Mar 2022 11:58:46 -0000
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
|
