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
|
Return-Path: <rsomsen@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 4AA58C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 15:30:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 45C4225248
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 15:30:08 +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 ZZu0LDLOrfHu
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 15:30:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com
[209.85.208.54])
by silver.osuosl.org (Postfix) with ESMTPS id 2640C2588A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 15:30:06 +0000 (UTC)
Received: by mail-ed1-f54.google.com with SMTP id l3so8301514edq.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 May 2020 08:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=VFT8bDvUvCzxFt39A9LaygKuiyK9xfzNCtFUcjSK650=;
b=o+8XFsK8isTUZB6eW/B8vLlAa5kH4WBDouo7OeMwMT9yBTQqdN9oq2hjGAnkLBOGVf
r69SCiFdy5ehn+oFoebOsSVBuUuMXUTPam7j/5SQu0vMYBYL7vX/X1cUMe54YwGpQ52o
Ta7lZs64ZQIwSXGX9Qv7vGu+ZLrdxUeVrlFGQmb116nJMB4p/zW4D2bNPjsNn86EhlEh
FbQYhUWXsBQNtD3pLs2xgsxtSX2Dt3CkdFVU+bldptr/5TY9dzEt/pu00gUBbvc/0NCi
D0C3OQNY+qgKDdU2sfwfTYTJxhD8xDW9Lb0J/99+Ut3SwXOS2Fiz5obxw2xyxqBmutBX
qk5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=VFT8bDvUvCzxFt39A9LaygKuiyK9xfzNCtFUcjSK650=;
b=tJRXp5fEvMSUXGRlxceW5yu8Wz00+iUqcBm2QBtup2NkD8b689SudQ0/aFdWqbHGKK
+lSX/pCqq0zMNprrGqrYZ4eF1K/N6qIeJW1CrAa54h85bzDBTquF7CEa0+D4xDw5jCtH
eGxnMwS0pBSKYXeyLmkDZ57WSISgMLz+TU8Ldakpw8zOHMmXUrjZXr5BJwqEns2CYKAF
/519UQA/m/piJ14JD6gSqArjYYJMjmRi6wBWqLJiZ1w/5NlQ9TrpqvzC354v13qvC+ED
Vi994erD44ZGPNeGLqNtsHXAm5XBUvDcuI5qskx9VjHvdvpRoigR1EaTnonoWFoAwj1P
awMg==
X-Gm-Message-State: AGi0PuYZfFtjj92sy2FoBTqAM30F6WfuYft6C9ZKVnrS5Bv+3bZF69Cx
WI26ieDL+folS7snqMQudDM6nRsrZSKE0DXQx93tbQKd
X-Google-Smtp-Source: APiQypJPeRTglHGGGi5/wDFQVZuyikJjrLhYskxrt/oGv/N1kBmfvGYsb/cAXQx2MNWGlqG+KZEi4oGSwFo55An1scM=
X-Received: by 2002:aa7:d60a:: with SMTP id c10mr14386302edr.66.1589211004055;
Mon, 11 May 2020 08:30:04 -0700 (PDT)
MIME-Version: 1.0
From: Ruben Somsen <rsomsen@gmail.com>
Date: Mon, 11 May 2020 17:29:51 +0200
Message-ID: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Mon, 11 May 2020 15:31:08 +0000
Subject: [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 15:30:08 -0000
Works today with single signer ECDSA adaptor signatures[0], or with
Schnorr + MuSig.
Diagram here:
https://gist.github.com/RubenSomsen/8853a66a64825716f51b409be528355f#file-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 complexity)
- Online/watchtower requirement for the timelock supporting chain (not
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 then
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 & keyBob 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 (= 3 tx protocol)
- Instead, Bob simply hands secretBob to Alice
- Likewise, Alice hands keyAlice to Bob to forego her claim on the refund_tx
- Bob continues to monitor the chain, because he'll have to respond if
Alice ever publishes the revoke_tx
More graceful protocol failure:
If the protocol aborts after step 1, Alice would have been forced to
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 from
the funding transaction. Publishing this transaction would also reveal
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: spendable
by Alice + Bob right away OR by Alice after a relative timelock. It is
important to note that this transaction must NOT be published during
step 3. Once Bob can complete the success_tx, the revoke_tx is needed
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 MUST
confirm before the timeout_tx becomes valid, which may become a
problem if fees suddenly rise. The refund_tx can also not be allowed
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 becomes
valid. The eltoo[2] method of paying for fees (requires
sighash_anyprevout) or a second CPFP-able output may be an improvement
here (and also mitigates fee rising issues), but note that this also
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 will
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 require
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/8853a66a64825716f51b409be528355f
Related work:
Tier Nolan Atomic Swap:
https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949
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-January/017595.html
[2] https://blockstream.com/eltoo.pdf
|
