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
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3BDF4C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 04:20:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 21ADA227A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 04:20:40 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id bW9o0dZ2zlrd
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 04:20:36 +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 silver.osuosl.org (Postfix) with ESMTPS id DF55820484
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2020 04:20:35 +0000 (UTC)
Date: Fri, 21 Aug 2020 04:20:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1597983632;
bh=ot2n25cDby0OlHd8a9Kzrv0Ok140rITh8wRjrTUDm+0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=dZeoywuCiXiMoBAnvATIMByu4+WVNfH198D5rilMbDjUh56r7fqIgb1qw2yvIAULX
XA2tpmppVWF4w9NnWqkuls/mJ65xBFISdGm1B1asD+/FlLbSDF8Oj7t7wkSDctVHbL
ypfdwb+OSlawEnZXlg59P9YRklQtTL4y3XIICACA=
To: Chris Belcher <belcher@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <WtKtWCdqIFVTTqw9-EggdsTIo6ejfP8my868MYyAqO8FUboiXWZUd0hw2PyvEKZNJxqAWJ_9BnOllAGEuUYYcA654amKTC4MSmO3TO4A7pU=@protonmail.com>
In-Reply-To: <e8ca67be-d07c-3f2e-4318-0d2bab061dd9@riseup.net>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
<xhRsCejqgUjoLy5hPMHgFcZdiqJsO7TfS0azWhis9-tvSgXodoKe7gN5IXyiVIVqUWSm7FoY-aBUaJCCDgixdWUN4n8EzhQlSNshsQeIFsw=@protonmail.com>
<e8ca67be-d07c-3f2e-4318-0d2bab061dd9@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
multi-transaction CoinSwap
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: Fri, 21 Aug 2020 04:20:40 -0000
Good morning,
> Right, so if the taker uses only a single maker then they must have more
> than one UTXO.
Spending one UTXO is fine, it is generating a transaction that has one outp=
ut that is problematic.
What needs to happen is that this single UTXO is spent to two outputs: the =
CoinSwap 2-of-2 and the change output.
This is because intermediate makers will have very high likelihood of gener=
ating such a pattern (it is unlikely they have an exact amount that a taker=
would require of them), and the occassional maker might have a very large =
UTXO that it can use for similar purposes.
One thing a taker can do would be to multipath its CoinSwap, i.e. it spends=
any number of UTXOs and creates two outputs, which are actually two separa=
te CoinSwap 2-of-2s to different makers.
As each maker is unaware of the other, this should be similar to the case w=
here the maker is an intermediate hop and is getting its incoming HTLC from=
another maker, which is unlikely to have a precise amount and will thus ha=
ve a transaction that has two outputs, the 2-of-2 CoinSwap and the change.
>
> This leak in the case of a taker spending a single UTXO also happens
> when the taker needs to create a branching route. I described this in my
> original email "Design for a CoinSwap implementation for massively
> improving Bitcoin privacy and fungibility" under the section "Combining
> multi-transaction with routing" (the second diagram).
>
> I think this might be unavoidable. If the taker has just one UTXO they'd
> be much better off using multiple makers for this reason.
>
> > - The makers can try timing the communications lag with the taker.
> > The general assumption would be that more makers =3D=3D more delay =
in taker responses.
> >
>
> Sounds like adding random delays would fix this. The protocol already
> involves waiting for a confirmation (average waiting time 10 minutes, at
> best) and might involve more confirmations for extra security and
> privacy. So adding a random delay of up to 0.5-1 minutes shouldnt cause
> too many issues.
> Also the Tor network can be pretty laggy so that might add enough noise
> anyway.
Indeed, this seems a bit of a long shot for the surveilling maker.
> > > =3D=3D=3D Miner fees =3D=3D=3D
> > > Makers have no incentive to pay any miner fees. They only do
> > > transactions which earn them an income and are willing to wait a very
> > > long time for that to happen. By contrast takers want to create
> > > transactions far more urgently. In JoinMarket we coded a protocol whe=
re
> > > the maker could contribute to miner fees, but the market price offere=
d
> > > of that trended towards zero. So the reality is that takers will pay =
all
> > > the miner fees. Also because makers don't know the taker's time
> > > preference they don't know how much they should pay in miner fees.
> > > The taker will have to set limits on how large the maker's transactio=
ns
> > > are, otherwise makers could abuse this by having the taker consolidat=
e
> > > maker's UTXOs for free.
> >
> > Why not have the taker pay for the first maker-spent UTXO and have addi=
tional maker-spent UTXOs paid for by the maker?
> > i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 =
BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs).
> > Disagreements on feerate can be resolved by having the taker set the fe=
erate, i.e. "the customer is always right".
> > Thus if the maker has to spend two UTXOs to make up the 0.4 BTC bag, it=
pays for the mining fees for that extra UTXO.
> > The maker can always reject the swap attempt if it has to spend multipl=
e UTXOs and would lose money doing so if the taker demands a too-high feera=
te.
>
> Having the taker pay for just one UTXO will have an unfortunate side
> effect of resulting in the maker's money being split up into a large
> number of UTXOs, because every CoinSwap they take part in has an
> incentive to increase their UTXO count by one. At the start of
> JoinMarket this was an issue where then a taker wanting to CoinJoin a
> large would come along and the result would be a huge CoinJoin
> transaction with many many small inputs. Perhaps the taker could pay for
> 2-3 UTXOs to counteract this. (Of course the exact number would be
> configurable by the taker user, but defaults usually don't get changed).
>
> I'm still not convinced with having makers contribute to miner fees. In
> JoinMarket we tried to get makers to contribute a little to miner fees
> and simply they never did in any meaningful way. The market has spoken.
> In terms of incentives makers are happy to wait a very long time, if we
> assume they're just HODLers then even if they earn a few thousand
> satoshis that's good.
>
> > > =3D=3D Contract transaction definitions =3D=3D
> > > Contract transactions are those which may spend from the 2-of-2 multi=
sig
> > > outputs, they transfer the coins into a contract where the coins can =
be
> > > spent either by waiting for a timeout or providing a hash preimage
> > > value. Ideally contract transactions will never be broadcast but thei=
r
> > > existence keeps all parties honest.
> > > M~ is miner fees, which we treat as a random variable, and ultimately
> > > set by whichever pre-signed RBF tx get mined. When we talk about the
> > > contract tx, we actually mean perhaps 20-30 transactions which only
> > > differ by the miner fee and have RBF enabled, so they can be broadcas=
ted
> > > in sequence to get the contract transaction mined regardless of the
> > > demand for block space.
> >
> > The highest-fee version could have, in addition, CPFP-anchor outputs, l=
ike those being proposed in Lightning, so even if onchain fees rise above t=
he largest fee reservation, it is possible to add even more fees.
> > Or not.
> > Hmm.
>
> I think RBF transactions are better because they ultimately use less
> block space than CPFP.
>
> There seems to be very little cost in signing many additional
> precomputed RBF transactions. So the taker and makers could sign
> transactions all the way up to 10000 sat/vbyte. I think this doesn't
> apply to Lightning, because bandwidth seems to be more constrained
> there: even a tiny micropayment for 1 satoshi would require 10x or 100x
> more bandwidth if every lightning htlc used precomputed RBF.
I was wondering if it would be a good idea actually if the **largest** fee =
RBF transaction had additional CPFP anchor outputs, not saying to replace t=
he entire group of RBF transactions entirely.
This is just in case of a very sudden increase in feerates that goes beyond=
the largest that was prepared beforehand.
"You cannot predict the feerates future" is becoming something of a mantra =
over in Lightning, though I guess a "big enough" spread of RBF transactions=
would work in practice >99% of the time.
> > Another thought: later you describe that miner fees are paid by Alice b=
y forwarding those fees as well, how does that work when there are multiple=
versions of the contract transaction?
>
> Alice only pays the miner fees for the funding transactions, not the
> contract transaction. The miner fees for the contract transactions are
> taken from the contract balance. The contract transactions are 1-input
> 1-output, and whoever ends up with the money will be the one who paid
> the miner fee.
Okay, that is much clearer.
> > > (Alice+timelock_A OR Bob+hash) =3D Is an output which can be spent
> > > either with Alice's private key
> > > after waiting for a relative
> > > timelock_A, or by Bob's private key by
> > > revealing a hash preimage value
> >
> > The rationale for relative timelocks is that it makes private key turno=
ver slightly more useable by ensuring that, after private key turnover, it =
is possible to wait indefinitely to spend the UTXO it received.
> > This is in contrast with absolute timelocks, where after private key tu=
rnover, it is required to spend received UTXO before the absolute timeout.
> > The dangers are:
> >
> > - Until it receives the private key, if either of the incoming or out=
going contract transactions are confirmed, every swap participant (taker or=
maker) should also broadcast the other contract transaction, and resolve b=
y onchain transactions (with loss of privacy).
> > - After receiving the private key, if the incoming contract transacti=
on is confirmed, it should spend the resulting contract output.
> > - It is possible to steal from a participant if that participant goes=
offline longer than the timeout.
> > This may imply that there may have to be some minimum timeout that =
makers indicate in their advertisements.
> > - The taker can detect if the first maker is offline, then if it =
is offline, try a contract transaction broadcast, if it confirms, the taker=
can wait for the timeout; if it times out, the taker can clawback the tran=
saction.
> > - This appears to be riskless for the taker.
> > - Against a similar attack, Lightning requires channel reserv=
es, which means the first hop never gains control of the entire value, whic=
h is a basic requirement for private key turnover.
> > - On the other hand, the taker has the largest timeout before it =
can clawback the funds, so it would wait for a long time, and at any time i=
n between the first maker can come online and spend using the hashlock bran=
ch.
> > - But the taker can just try on the hope it works; it has not=
hing to lose.
> > - This attack seems to be possible only for the taker to mount.
> > Other makers on the route cannot know who the other makers are,=
without cooperation of the taker, who is the only one who knows all the ma=
kers.
> > - On the other hand, the last maker in the route has an outgo=
ing HTLC with the smallest timelock, so it is the least-risk and therefore =
a maker who notices its outgoing HTLC has a low timeout might want to just =
do this anyway even if it is unsure if the taker is offline.
>
> Every off-chain protocol like this has the livelyness requirement. Each
> party must always be watching the chain and be ready to broadcast
> something in response. I'm not sure how any of this relates to the
> choice of relative vs absolute time locks.
Absolute timelocks mean that you can set a timer where you put your node to=
sleep without risk of loss of funds (basically, once the absolute timelock=
s have resolved, you can forget about CoinSwaps).
But I think the ability to spend at any time would be better, and getting 1=
00% online 144 blocks a day, 2016 blocks a retargeting period is becoming m=
ore and more feasible.
>
> You're right that attempting such an move by the taker is riskless, but
> its not costless. The taker sets up the entire CoinSwap protocol because
> they wanted more privacy; but if the taker broadcasts the Alice contract
> transaction and waits for the timeout, then all they've achieved is
> spent miner fees, got their own coin back and draw attention to it with
> the unusual HTLC script. They've achieved no benefit from what I see, so
> they won't do this. Any taker or maker who attempts anything like this
> will be spending miner fees.
They would be spending miner fees *from the funds being stolen*, thus still=
costless.
In particular, let us imagine a simple 1-maker swap.
* The taker and the maker complete the swap.
* The taker now has possession of:
* The private key for its incoming HTLC.
* The pre-signed contract transaction for its outgoing HTLC.
* The taker spends from its incoming HTLC using the private key.
* The maker ignores this, because this is just normal operation.
* Fees paid for this is not an **additional** cost, because a taker that =
wants to put its freshly-private funds into cold storage will do this anywa=
y.
* The taker gets a fresh, private coin from this incoming HTLC, so it get=
s the privacy it paid for.
* The taker waits for the incoming-HTLC-spend to confirm.
* The taker broadcasts the pre-signed contract transaction, in the hope tha=
t the maker is offline.
* The fees paid for this are from the contract transaction that the taker=
is trying to steal.
Even if the theft attempt fails, the taker has already gotten its priva=
te money out, and is thus not risking anything.
* Semantically, the outgoing HTLC is already "owned" by the maker (the ma=
ker has private key to it).
* Thus, the taker commits an action that the maker pays fees for!
* The maker cannot react except to spend via the hashlock branch.
In particular, because the taker-incoming (maker-outgoing) UTXO is alre=
ady spent, it cannot retaliate by also broadcasting the contract transactio=
n of the taker-incoming (maker-outgoing) HTLC.
* The theft succeeds (the timelock passes) because the maker happens to be =
offline for that long.
* This is "free money" to the taker, who has already gotten what it paid =
for --- private money in cold storage --- from the CoinSwap.
* Even if the stolen fund reveals the contract, the taker can re-acquire =
privacy for the funds it stole for free, by paying for --- wait for it --- =
another CoinSwap for its swag.
Using an absolute timelock (implemented by a `nLockTime` tx directly off th=
e 2-of-2, ***not*** `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script 2p-=
ECDSA (again implemented by a tx directly off the 2-of-2) instead of a hash=
lock, seems to avoid this, I think, at the cost of reducing the utility of =
private key turnover by having a deadline where the private key *has to* be=
used.
This is because there is no contract transaction that is share-owned by bot=
h participants in the swap.
Instead there are two distinct transactions with separate ownerships: a tim=
eout tx (that is owned by the participant paying for the HTLC/PTLC) and a c=
laim tx (that is owned by the participant accepting the HTLC/PTLC).
> > - Participants might want to spend from the UTXO to a new address aft=
er private key turnover anyway.
> > Makers could spend using a low-fee RBF-enabled tx, and when another=
request comes in for another swap, try to build a new funding tx with a hi=
gher-fee bump.
> >
>
> I don't think this will happen very often. It's spending money on block
> space for not much benefit. If the maker ever decides to shut down their
> maker they can transfer all their coins in HTLCs to single-sig
> transactions exclusively controlled by them, but in normal operation I
> doubt it will happen.
Accidents can happen (e.g. somebody trips over the power cord of the maker =
hardware), so hedging this somewhat might give a useful safety net.
>
> The attack I describe works because Alice chooses both MA~ and MB~. The
> attack is that Alice chooses MA~ to be a very low value (e.g. 1 sat/vb)
> and chooses MB~ to be a very high value (e.g. 1000 sat/vb). Then Alice
> intentionally sabotages the CoinSwap and forces it to go to the timeout
> case, what happens is that Bob's wallet balance falls by much more than
> Alice's, because MB~ > MA~. So this is a DOS attack: Alice can waste
> Bob's resources without wasting much of her own.
Ah, right, that is clearer.
> > > =3D=3D EC tweak to reduce one round trip =3D=3D
> > > When two parties are agreeing on a 2-of-2 multisig address, they need=
to
> > > agree on their public keys. We can avoid one round trip by using the =
EC
> > > tweak trick.
> > > When Alice, the taker, downloads the entire offer book for the liquid=
ity
> > > market, the offers will also contain a EC public key. Alice can tweak
> > > this to generate a brand new public key for which the maker knows the
> > > private key. This public key will be one of the keys in the 2-of-2
> > > multisig. This feature removes one round trip from the protocol.
> > > q =3D EC privkey generated by maker
> > > Q =3D q.G =3D EC pubkey published by maker
> > > p =3D nonce generated by taker
> > > P =3D p.G =3D nonce point calculated by taker
> > > R =3D Q + P =3D pubkey used in bitcoin transaction
> > > =3D (q + p).G
> >
> > Whoa whoa whoa whoa.
> > All this time I was thinking you were going to use 2p-ECDSA for all 2-o=
f-2s.
> > In which case, the private key generated by the taker would be sufficie=
nt tweak to blind this.
> > In 2p-ECDSA, for two participants M =3D m * G; T =3D t * G, the total k=
ey is m * t * G =3D m * T =3D t * M.
> > Are you going to use `2 <T> <Q+P> 2 OP_CHECKMULTISIG` instead of 2p-ECD=
SA?
> > Note that you cannot usefully hide among Lightning mutual closes, becau=
se of the reserve; Lightning mutual closes are very very likely to be spent=
in a 1-input (that spends from a 2-of-2 P2WSH), 2-output (that pays to two=
P2WPKHs) tx.
>
> Yes, I intend for 2p-ECDSA to be used eventually, but for the first
> version I'll only implement regular multisigs with OP_CHECKMULTISIG.
> Once all the other details of this protocol are implemented correctly
> and mostly-bug-free then 2p-ECDSA can be added. It can be added in the
> protocol steps 0-1, 3-5 and 7-9.
Okay, that is clearer.
I think 2p-ECDSA should be first priority after getting a decent alpha vers=
ion.
> This document also doesn't talk about PayJoin-with-CoinSwap, but that
> can be added later too.
2p-ECDSA with Scriptless Script potentially gives a lot more privacy than a=
ny PayJoin IMO, due simply to the much larger anonymity set, and there are =
enough chain-analysis-heuristic-breaking shenanigans we can implement with =
plain CoinSwap, I think.
Regards,
ZmnSCPxj
|