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
|
Return-Path: <rsomsen@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 40CA9C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 17:50:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 35E6388167
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 17:50:39 +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 swmEl0rCEbbg
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 17:50:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com
[209.85.218.46])
by hemlock.osuosl.org (Postfix) with ESMTPS id 1F3D888012
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 17:50:36 +0000 (UTC)
Received: by mail-ej1-f46.google.com with SMTP id se13so1997544ejb.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 10:50:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=Fe1yqUeXayV+8YEJuDD+zyumtbY1abztHDb+p0IxZdo=;
b=NaDNFZMH1VPH99rfnrj5NAssyKsSdkNjPpO1Ktl0OThC2WB17l1RhdHgXOi2mS/QTm
xCX8rhafwO53kC57Kn6JN5eV1ukL0DnBonXj6senxW+Jd904JoFi7VLeUaMHdsWPr923
ku+Ym+x68iebKJorGfrAztUMmrRnC8BtkqIFFmjCjchdnQu2mY7i341Q8refI7sDQ7pH
4vTPaBH8A42xir7+GIHowkl0Oc9CuVTsXoI7u2pJ/n6PGrZPK1UamUWz+U21p+3HjGNu
4krkNWfBMqTPyN8+MgZA2JRE90U3nLsRIrItfa7h6ZhnnO+S5OTfb49akcPTQSrz59DR
59eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=Fe1yqUeXayV+8YEJuDD+zyumtbY1abztHDb+p0IxZdo=;
b=dAseChKPRK7DPSgSSRxHc+XY4DP0c97amJcXqTTfT1rxqJe9aiw7OQHBVfRrKmoxmJ
47ZCAhdCZbQYKVRQSlQQ/1xPDSxzLlugM1mCT6ruVj/mYIoyS2DKyirexaXkhiCU5jzP
QY5WkPBpwD5ZJnLen6lOxnLYLaHlAVn+/WR55s7PW9zAKvOnQBREw80tER5i/8IWBy1o
AuOiF80k4twu93jndr/yLqBT8grAroYPCwUK0PMUDYN1vvgeO7KkoteoG/zniiJ7+6FP
xRqfSY5ENIbT8daob4a6MOBLc9qa/ccb13y+WL9unQTMXWSfZE5g6X8cZFaOK9rbZsB+
/UZA==
X-Gm-Message-State: AGi0PubtPJjWGGw86+UQYn4u+cGZX6+Z+sVm7xmDFksOTdrdYhOQIVDz
oxqQYN1FRgSHaWLuWOHIfCdQRpagf3DFAYJE9dz1Jag2
X-Google-Smtp-Source: APiQypIj8hedlISad0UrIInK4oQxnoBd23tA0LO82e+bl/z5N4w2j45lkTK43RLIpih1HIzy+jwvhmVeWDPnnRd9vBo=
X-Received: by 2002:a17:906:17c5:: with SMTP id
u5mr14462023eje.275.1589219434204;
Mon, 11 May 2020 10:50:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
<vtu_ujJwxJDSC3w4QI5VlQ8WfkxaRg1Jk4nSNybgeYSWgGrN7sJiKa9dNzb0tDbRBdVhT4p60v-j6C2F8LmFxMLUTi_VtCznWRb56GVlvu8=@protonmail.com>
In-Reply-To: <vtu_ujJwxJDSC3w4QI5VlQ8WfkxaRg1Jk4nSNybgeYSWgGrN7sJiKa9dNzb0tDbRBdVhT4p60v-j6C2F8LmFxMLUTi_VtCznWRb56GVlvu8=@protonmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Mon, 11 May 2020 19:50:21 +0200
Message-ID: <CAPv7TjYePyEt2YMg3J_KinK6Lv6SSLAF2nrOj79_oVt8qBXN0w@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 11 May 2020 17:50:46 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] SAS: Succinct Atomic Swap
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: Mon, 11 May 2020 17:50:39 -0000
Hi ZmnSCPxj,
Thanks for your feedback :)
>CoinSwap for privacy is practically a "cross" chain atomic swap with the s=
ame chain and token for both sides of the swap
I agree, I didn't mean to imply that was new, only that this protocol
makes it more efficient.
>"Instead, Bob simply hands secretBob to Alice" is basically the same as pr=
ivate key turnover
Thanks for the link. I will add it to the links at the bottom of the
write-up, as I agree it's related. Do note there are a few key
differences:
- The swap is set up in an "asymmetric" way with only timelocks on one
side, so on the other side the swap *never* expires
- The timelocks are set up in such a way that the swap does not expire
unless Alice starts the relative timelock countdown (the revoke
transaction)
- This relative timelock setup comes practically for free, because the
asymmetry naturally requires that kind of setup
>The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin an=
d similar blockchains, by signing a specific `nSequence`
"OR Alice in +1 day" is "refund transaction #1" from the diagram. If
I'm not mistaken, the change you are suggesting is exactly how "refund
transaction #2" is constructed. Note that #1 and #2 serve the same
purpose. Strictly speaking, #1 is not needed at all, but it's there to
give Alice the option to back out of the swap in two transactions as
opposed to three.
>It strikes me that the relative locktime is unnecessary on the output of t=
his refund tx
I believe I addressed this in the FAQ section (the question about
absolute timelocks). An absolute timelock is possible, but you then
need to make absolutely sure that the revoke transaction confirms in
time, otherwise the protocol can fail (namely after Bob has received a
copy of the success transaction and just waits and does nothing). You
also lose the ability to keep the channel open indefinitely.
>having a variety of different versions of the transactions with different =
feerates could be used
That's a good point.
>As long as the one resolving a particular side of the swap is the one that=
ocmpletes the signature (which I believe holds true for all branches?)
Unfortunately this does not hold for the revoke transaction. It would
be a bit awkward if Alice had a high fee copy after the protocol
completes. She could send it to the blockchain and essentially Bob
would be paying for it. I'm not as concerned about the other
transactions, because those could all be bumped with CPFP if needed,
but having different feerates would be nice.
And a general comment about privacy: it seems inevitable that some
information will be leaked if the protocol does not complete
cooperatively. As long as the cooperative case is not traceable, that
seems about as good as it can get. That's my view, at least. I'd be
curious to hear if you see that differently.
Cheers,
Ruben
On Mon, May 11, 2020 at 6:45 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Ruben,
>
> CoinSwap for privacy is practically a "cross" chain atomic swap with the =
same chain and token for both sides of the swap, see also this set of ideas=
: https://github.com/AdamISZ/CoinSwapCS/issues/53
>
> "Instead, Bob simply hands secretBob to Alice" is basically the same as p=
rivate key turnover, as best as I can understand it, and gives significant =
advantages, also described in passing here: https://lists.linuxfoundation.o=
rg/pipermail/bitcoin-dev/2020-May/017816.html
>
> Overall, this looks very much like a working CoinSwap as well.
>
> The Refund tx does not need anything more than a 2-of-2 script.
> The "OR Alice in +1 day" branch can be implemented, at least on Bitcoin a=
nd similar blockchains, by signing a specific `nSequence`, or if the chain =
forking predates BIP68, by using absolute locktimes and signing a specific =
`nLockTime`, with the destination being just "Alice".
> This should help privacy, as now all `scriptPubKey`s will be 2-of-2 (or P=
2PKH with 2p-ECDSA).
>
> (It strikes me that the relative locktime is unnecessary on the output of=
this refund tx --- as long as both participants agree on either Alice or B=
ob having a longer locktime, you can just use the locktime on the refund tx=
directly as backout; see the topic "`nLockTime`-protected Backouts" on the=
CoinSwapCS issue link)
>
> If you are willing to accept protocol complexity, having a variety of dif=
ferent versions of the transactions with different feerates could be used r=
ather than the Decker-Russell-Osuntokun "eltoo" bring-your-own-fees method.
> In terms of privacy this is better as you would not be using anything oth=
er than the most boring `SIGHASH_ALL` signing flag, whereas the Decker-Russ=
ell-Osuntokun will be identifiable onchain (and thus possibly flag the tran=
saction as "of interest" to surveillors) due to use of `SIGHASH_ANYPREVOUT`=
.
> As long as the one resolving a particular side of the swap is the one tha=
t ocmpletes the signature (which I believe holds true for all branches?) th=
en it would select the version of the transaction with the best feerate, wh=
ich it effectively pays out to what it recovers.
>
>
> Regards,
> ZmnSCPxj
>
>
> > Works today with single signer ECDSA adaptor signatures[0], or with
> > Schnorr + MuSig.
> >
> > Diagram here:
> > https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#fi=
le-succinctatomicswap-svg
> >
> > Advantages:
> >
> > - Requires merely two on-chain transactions for successful completion=
,
> > as opposed to four
> >
> > - Scriptless, and one of the chains doesn't need to support timelocks
> > - Can be used for efficient privacy swaps, e.g. Payswap[1]
> >
> > Disadvantages:
> >
> > - Access to money is contingent on remembering secrets (backup comple=
xity)
> > - Online/watchtower requirement for the timelock supporting chain (no=
t
> > needed with 3 tx protocol)
> >
> > Protocol steps:
> >
> > 0.) Alice & Bob pre-sign the following transactions, with exception=
of
> > the signatures in [brackets]:
> >
> > - success_tx (money to Bob): [sigSuccessAlice] + [sigSuccessBob]
> > - revoke_tx (timelock): sigRevokeAlice + sigRevokeBob, which must the=
n
> > be spent by:
> > -- refund_tx (relative timelock, refund to Alice): [sigRefundAlice]
> >
> >
> > - {sigRefundBob}
> > -- timeout_tx (longer relative timelock, money to Bob):
> > sigTimeoutAlice + [sigTimeoutBob]
> >
> > {sigRefundBob} is an adaptor signature, which requires secretAlice =
to complete
> >
> > 1.) Alice proceeds to lock up 1 BTC with Bob, using keyAlice & keyB=
ob as pubkeys
> >
> > If protocol is aborted after step 1:
> >
> >
> > - Alice publishes the revoke_tx, followed by the refund_tx &
> > sigRefundBob, to get her BTC back
> >
> > - If Alice neglects to publish the refund_tx in time, Bob will claim
> > the BTC with the timeout_tx
> >
> > 2.) Bob locks up altcoins with Alice, using secretAlice & secretBob=
as pubkeys
> >
> > If protocol is aborted after step 2:
> >
> > - Once Alice publishes sigRefundBob, Bob learns secretAlice and
> > regains control over the altcoins
> >
> > 3.) Protocol completion:
> >
> > - Alice hands adaptor signature {sigSuccessAlice} to Bob, which
> > requires secretBob to complete
> >
> > - Bob could now claim the BTC via the success_tx, reveal secretBob,
> > and thus give Alice control over the altcoins (=3D 3 tx protocol)
> >
> > - Instead, Bob simply hands secretBob to Alice
> > - Likewise, Alice hands keyAlice to Bob to forego her claim on the re=
fund_tx
> > - Bob continues to monitor the chain, because he'll have to respond i=
f
> > Alice ever publishes the revoke_tx
> >
> > More graceful protocol failure:
> >
> > If the protocol aborts after step 1, Alice would have been forced t=
o
> > make three transactions in total, while Bob has made none. We can
> > reduce that to two by introducing a second refund_tx with timelock
> > that can be published ahead of the revoke_tx and directly spends fr=
om
> > the funding transaction. Publishing this transaction would also rev=
eal
> > secretAlice to Bob via an adaptor signature. In the 3 tx protocol,
> > this output can go directly to Alice. In the 2 tx protocol with
> > online/watchtower requirement, this output needs a script: spendabl=
e
> > by Alice + Bob right away OR by Alice after a relative timelock. It=
is
> > important to note that this transaction must NOT be published durin=
g
> > step 3. Once Bob can complete the success_tx, the revoke_tx is need=
ed
> > to invalidate the success_tx prior to revealing secretAlice.
> >
> > FAQ:
> >
> > - Why not allow Alice to still claim the altcoins if she accidentally
> > lets Bob publish the timeout_tx?
> >
> > Alice could send the revoke_tx at the same time, revealing both
> > secrets and causing likely losses. This can be solved by adding yet
> > another transaction, but it wouldn't be efficient and wouldn't
> > motivate Alice to behave.
> >
> > - Is it possible to implement this protocol on chains which only
> > support absolute timelocks?
> >
> > Yes, but then Bob must spend his swapped coins before the timelock
> > expires (or use the 3 tx protocol). Be aware that the revoke_tx MUS=
T
> > confirm before the timeout_tx becomes valid, which may become a
> > problem if fees suddenly rise. The refund_tx can also not be allowe=
d
> > to CPFP the timeout_tx, as they must confirm independently in order=
to
> > invalidate the success_tx first.
> >
> > - Can't Alice just publish the revoke_tx after protocol completion?
> >
> > Yes, she'd first have to move the altcoins (to invalidate
> > secretAlice), and could then try to claim the BTC by publishing the
> > revoke_tx, forcing Bob to react on-chain before the refund_tx becom=
es
> > valid. The eltoo[2] method of paying for fees (requires
> > sighash_anyprevout) or a second CPFP-able output may be an improvem=
ent
> > here (and also mitigates fee rising issues), but note that this als=
o
> > increases the required amount of tx data if the protocol doesn't
> > complete successfully.
> >
> > - Can this be made to work with hash locks?
> >
> > Yes, by making the altcoins spendable via sigAlice + preimageBob OR
> > sigBob + preimageAlice, and ensuring the contracts on the BTC side
> > reveal either pre-image. Do note that this is not scriptless and wi=
ll
> > thus increase the transaction size.
> >
> > Open question:
> >
> > Perhaps it's possible to perform an atomic swap in and out of
> > Lightning with only a single on-chain transaction. This would requi=
re
> > some kind of secondary set of HTLCs, allowing the sender to cancel =
a
> > Lightning payment by revealing a secret after a certain period of
> > time.
> >
> > -- Ruben Somsen
> >
> > Thanks to Lloyd Fournier for feedback and review.
> >
> > If you find any further errors, I will endeavor to fix them here:
> > https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355=
f
> >
> > Related work:
> >
> > Tier Nolan Atomic Swap:
> > https://bitcointalk.org/index.php?topic=3D193281.msg2224949#msg2224=
949
> > Monero Atomic Swap:
> > https://github.com/h4sh3d/xmr-btc-atomic-swap/blob/master/README.md
> >
> > [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-=
November/002316.html
> >
> > [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-Ja=
nuary/017595.html
> >
> > [2] https://blockstream.com/eltoo.pdf
> >
> >
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
|