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
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
|
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 250D5C016E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 04:53:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 205CF8880C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 04:53:59 +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 9F+E5fN2xTND
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 04:53:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
[185.70.40.132])
by hemlock.osuosl.org (Postfix) with ESMTPS id C040A887D1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 04:53:56 +0000 (UTC)
Date: Wed, 03 Jun 2020 04:53:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1591160033;
bh=uWHSL2zSVfDESPxmcnNI4XHkvEjyHLwWEJoz2/WPe2c=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=NXxGfmh2aaBhKg2mYqjU81xJzJPs8nctP83gFHUmHV0211gTCEGFpCaYiC8UMUFuJ
rTBRf8rEOpz/yinyskLyRTeTk1NDIlV80xaWLrFDxsqo/rXct3mMjtiF9B0T1ga6Af
F5YB2K1VuSsbA8o+J5WT4Yu4Q76nrhjpvsNVS0Dw=
To: Chris Belcher <belcher@riseup.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com>
In-Reply-To: <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
<CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
<VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
<cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
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: Wed, 03 Jun 2020 04:53:59 -0000
Good morning Chris,
> > Good morning Ruben and Chris,
>
> > I am not in fact convinced that PayJoin-with-CoinSwap adds that much pr=
ivacy.
> > These transactions:
> >
> > +---+ +---+
> > Alice ---| |--| |--- Bob
> > Alice ---| | | |
> > Bob ---| | +---+
> > +---+
> >
> >
> > Are not really much different in coin ownership analysis from these:
> >
> > +---+ +---+
> > Alice ---| |----| |--- Bob
> > Alice ---| | +--| |
> > +---+ | +---+
> > Bob ---------+
> >
>
> The main benefit of PayJoin-with-CoinSwap is it breaks the
> common-input-ownership heuristic, which is a major widely used
> heuristic. It would be a big win if that heuristic could be broken.
>
> PayJoin-with-CoinSwap would be useful if Alice is trying to recover some
> privacy which was previously degraded, for example if she is spending
> from a reused address or from an address linked to her identity. If she
> does a PayJoin with the reused address then some other economic entity
> would have his activity linked with Alice's.
>
> Just the fact that PayJoin-with-CoinSwap exists would improve privacy
> for people who don't use it, for example if someone buys bitcoin from an
> exchange that knows their identity and then co-spends it with other
> coins they obtained another way. The fact that PayJoin exists means an
> adversary cannot assume for sure that this user really owns that other
> address which was co-spent. This doesn't apply for regular CoinSwap,
> which only ever breaks the transaction graph heuristic, so in our
> example the destination the coins are sent to would be uncertain, but
> that the co-spent inputs are owned by the same person would be certain
> in a world where PayJoin didn't exist.
Alice can do PayJoin with a payee Carol that supports normal PayJoin, for s=
imilar overall results.
Though I suppose there is a mild advantage still with supporting it on the =
funding tx of the first transaction, as you noted.
> > But S6 has the mild advantage that all the funding transactions paying =
to 2-of-2s can appear on the same block, whereas chaining swaps will have a=
particular order of when the transactions appear onchain, which might be u=
sed to derive the order of swaps.
>
> On the other hand, funds claiming in S6 is also ordered in time, so
> someone paying attention to the mempool could guess as well the order of
> swaps.
>
> I think this is wrong, and that it's possible for the funding
> transactions of chained/routed swaps to all be in the same block as well.
>
> In CoinSwap it's possible to get DOS'd without the other side spending
> money if you broadcast your funding transaction first and the other side
> simply disappears. You'd get your money back but you have to waste time
> and spend miner fees. The other side didn't spend money to do this, not
> even miner fees.
>
> From the point of view of us as a maker in the route, we know we won't
> get DOS'd like this for free if we only broadcast our funding
> transaction once we've seen the other side's funding transaction being
> broadcast first. This should work as long as the two transactions have a
> similar fee rate. There might be an attack involving hash power: If the
> other side has a small amount of hash power and mines only their funding
> transaction in a manner similar to a finney attack, then our funding
> transaction should get mined very soon afterwards by another miner and
> the protocol will continue as normal. If the other side has knowledge of
> the preimage and uses it to do CPFP and take the money, then we can
> learn that preimage and do our own CPFP to get our money back too.
How about RBF?
A taker Alice can broadcast the funding tx spending its own funds.
The funding tx spends funds controlled unilaterally by Alice.
Alice can sign a replacement transaction for those funds, spending them to =
an address with unilateral control, and making the funding tx output with a=
ll the obligations attached never get confirmed in the first place.
The chances may be small --- Bob can certainly monitor for Alice broadcasti=
ng a replacement and counter-broadcast its own replacement --- but the risk=
still exists.
TANSTAAGM (There Aint No Such Thing As A Global Mempool) also means Alice c=
ould arrange the replacement by other means, such as not using the RBF-enab=
led flag, broadcasting the self-paying replacement near miner nodes, and br=
oadcasting the CoinSwap-expected funding tx near the Bob fullnode; Bob full=
node will then reject attempts to replace it, but miners will also reject t=
he CoinSwap-expected funding tx and it will not confirm anyway.
With the pre-SAS 4-tx setup, this potentially allows Alice to steal the fun=
ds of Bob; after Alice gets its funding-tx-replacement confirmed together w=
ith the Bob honest-funding-tx, Alice can use the contract transaction and p=
ublish the preimage to take the Bob funds.
Since the Alice-side funding tx has been replaced, knowledge of the hash pr=
eimage will not help Bob any: the Alice funding tx has been replaced and Bo=
b cannot use the preimage to claim it (it does not exist).
With SAS Alice cannot outright steal the Bob funds, but the Bob funds will =
now be locked in a 2-of-2 and Alice can take it hostage (either Bob gives u=
p on the funds, i.e. donates its value to all HODLers, or Bob gives most of=
the value to Alice).
For the avoidance of theft, it is probably better for Bob to wait for Alice=
-side funding tx to confirm, probably deeply because reorgs suck.
This at least makes it costly to perform this attack; you have to lock more=
of your funds longer in order to induce a competitor to lock its funds.
Come to think of it, the same issue probably holds for S6 as well, the fund=
ing tx with the longest timelock has to confirm first before the next is ev=
en broadcast, bleah.
> An interesting tangent could be to see if it's possible to make private
> key handover work with S6. A nice side-effect of private key handover is
> that the transfer of possession of the coins happens off-chain, so then
> paying attention to the mempool won't help an adversary much.
It certainly seems quite possible; each participant in S6 has a fixed "prev=
ious" and "next" participant.
Of course, this requires a secure tunnel, and my understanding of your plan=
for SwapMarket is that the taker Alice serves as the broadcast medium betw=
een all makers and itself.
So, in an S6 sequence of Alice -> Bob1 -> Bob2 -> Alice, after Alice provid=
es the preimage, Bob2 encrypts the private key being handed over in an asym=
metric encryption that only Alice can open (e.g. using some known pubkey of=
Alice, there are many to choose from), Bob1 similarly encrypts its privkey=
for Bob2, and Alice encrypts the private key to Bob1, and Alice can then b=
roadcast all those data to all participants, and only the correct participa=
nt will be able to decrypt it.
---
On another privacy-related note, S6 mildly leaks to each maker its position=
in the route, via the timelocks.
Each Bob has to know the timelocks it is offered and which it will offer to=
the next participant, and the timelocks will be larger the further away th=
at Bob is from the Alice taker.
This is a mild privacy leak, one that seems unremovable to me.
(It also exists in Lightning Network as well: we suggest the use of "shadow=
routes" to artificially increase the distance of forwarding nodes, as a mi=
tigation.)
Regards,
ZmnSCPxj
|
