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
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6AECBC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 31 May 2020 02:31:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 58D4887FA4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 31 May 2020 02:31:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Pu9kL7MQTTD0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 31 May 2020 02:31:02 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
[185.70.40.140])
by hemlock.osuosl.org (Postfix) with ESMTPS id 5B7C787E65
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 31 May 2020 02:31:02 +0000 (UTC)
Date: Sun, 31 May 2020 02:30:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1590892259;
bh=VpJIAASVaHwxlDPd/GO9fvF/h/IoFWX7RG9oHI6B7C0=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=xdn/1rK0X3ey+6dODstIalZ8BuIYG32sY6p4NofoVLYYoaf/M/cmeXJHJNKkATD71
ybk2Qv2JTsgNU2W0hGWDJ/RNp37ZqY9M1fx7/2Bu7podcZdFCfE5PJXQ+quRwG7jYw
muGWOMBLU2tIs0zBfhoBzgXzba8Vz7+9YPJS8zIc=
To: Ruben Somsen <rsomsen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
In-Reply-To: <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
<CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
massively improving Bitcoin privacy and fungibility
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: Sun, 31 May 2020 02:31:04 -0000
Good morning Ruben and Chris,
> >For a much greater anonymity set we can use 2-party ECDSA to create 2-of=
-2 multisignature addresses that look the same as regular single-signature =
addresses
>
> This may perhaps be counter-intuitive, but SAS doesn't actually require m=
ultisig for one of the two outputs, so a single key will suffice. ECDSA is =
a signing algorithm that doesn't support single key multisig (at least not =
without 2p-ECDSA), but notice how for the non-timelocked SAS output we neve=
r actually have to sign anything together with the other party. We swap one=
of the two keys, and the final owner will create a signature completely on=
their own. No multisig required, which means we can simply use MuSig, even=
today without Schnorr.
Just to be clear, you mean we can use the MuSig key-combination protocol fo=
r the non-timelocked SAS output, but (of course) not the signing protocol w=
hich is inherently Schnorr.
Then knowledge of both of the original private keys is enough to derive the=
single combined private key.
> Of course the other output will still have to be a 2-of-2, for which you =
rightly note 2p-ECDSA could be considered. It may also be interesting to co=
mbine a swap with the opening of a Lightning channel. E.g. Alice and Bob wa=
nt to open a channel with 1 BTC each, but Alice funds it in her entirety wi=
th 2 BTC, and Bob gives 1 BTC to Alice in a swap. This makes it difficult t=
o tell Bob entered the Lightning Network, especially if the channel is open=
ed in a state that isn't perfectly balanced. And Alice will gain an uncorre=
lated single key output.
Dual-funding could be done by a single-funding Lightning open followed by a=
n onchain-to-offchain swap.
Though the onchain swap would have to be done, at least currently, with has=
hes.
> >=3D=3D=3D PayJoin with CoinSwap =3D=3D=3D
>
> While it's probably clear how to do it on the timelocked side of SAS, I b=
elieve PayJoin can also be applied to the non-timelocked side. This does re=
quire adding a transaction that undoes the PayJoin in case the swap gets ab=
orted, which means MuSig can't be used. Everything else stays the same: onl=
y one tx if successful, and no timelock (=3D instant settlement). I can exp=
lain it in detail, if it happens to catch your interest.
I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much priv=
acy.
These transactions:
+---+ +---+
Alice ---| |--| |--- Bob
Alice ---| | | |
Bob ---| | +---+
+---+
Are not really much different in coin ownership analysis from these:
+---+ +---+
Alice ---| |----| |--- Bob
Alice ---| | +--| |
+---+ | +---+
Bob ---------+
The latter is possible due to private key handover, the intermediate output=
becomes owned solely by Bob and Bob can add many more inputs to that secon=
d transaction unilaterally for even greater confusion to chain analysis, ba=
sically private key handover gets us PayJoin for free.
It also removes the need for Bob to reveal additional UTXOs to Alice during=
the swap protocol; yes PoDLE mitigates the privacy probing attack that Ali=
ce can mount on Bob, but it is helpful to remember this is "only" a mitigat=
ion.
Now of course things are different if Alice is paying some exact amount to =
Carol, and Alice wants to dissociate her funds from the payment.
The difference is then:
+---+ +---+
Alice ---| |----| |--- Bob
Alice ---| |--+ | |
Bob ---| | | +---+
+---+ +--------- Alice Change
+---+ +---+
Bob ---| |----| |--- Carol
| |--+ +---+
+---+ |
+--------- Bob Change
Versus:
+---+ +---+
Alice ---| |----| |--- Bob
Alice ---| | +--| |
+---+ | +---+
Bob ---------+
+---+ +---+
Bob ---| |----| |--- Carol
| |--+ | |--- Alice Change
+---+ | +---+
+--------- Bob Change
In the above, with PayJoin on the first-layer transaction, the Alice Change=
is correlated with Alice and Bob inputs, whereas with the PayJoin on the s=
econd the Alice change is correlated with Bob inputs and Carol outputs.
But if Alice, using commodity CoinSwap wallets, always has a policy that al=
l sends are via CoinSwap (a reasonable policy, similar to the policy in Joi=
nMarket of ensuring that all spends out of the wallet are via CoinJoin), th=
en the above two trees are not much different for Alice in practice.
The Alice Change will be swapped with some other maker anyway when it gets =
spent, so what it correlates with will not be much of a problem for Alice.
At the same time, with PayJoin on the second-layer transaction (possible du=
e to private key turnover, which is an inherent part of the SAS protocol):
* Bob does not have to reveal any other coins it owns to Alice other than w=
hat it is directly swapping, removing a privacy probe vector.
* Bob can unilaterally combine more than one input to the second transactio=
n going to Bob, which further increases the uncertainty of clustering aroun=
d the inputs from Alice than just adding *one* input.
---
A thing I have been trying to work out is whether SAS can be done with more=
than one participant, like in [S6](https://joinmarket.me/blog/blog/multipa=
rty-s6/).
So far, I have not figured out a way to make it multiparty (multihop?).
Because the secret being transported is a private key that protects a speci=
fic UTXO, it seems it is not possible to safely use the same secret across =
more than two parties.
Perhaps others have come ideas?
Regards,
ZmnSCPxj
|
