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
|
Return-Path: <dp@simplexum.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5254DC016E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 09:01:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 41B1287FB5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 09:01:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id GRGn7TxHaFKI
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 09:01:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
by whitealder.osuosl.org (Postfix) with ESMTPS id EECB087F8C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Jun 2020 09:01:35 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id 31E07260022D;
Wed, 3 Jun 2020 09:01:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1591174893;
bh=Swl71AlhE6+7V5LrgPzvkFk1FjBCj04HAVHQq/BUPDU=;
h=Date:From:To:Cc:Subject:In-Reply-To:References;
b=b+7I1B/k4NHm6z0SrychEk9yuTtkiFeyqnZLjzpB+oiMAg5aze8gX7nPgPsfKvpDP
XRFFrGGByLA6UpnXE1MTm4VoMZjCiOKUcor0jbbsAvVABkG2mudlprvsDWsArpFY/A
aEPFW47nJEUYmmLFbh2/778wYVEfGEol/0z0gQA4=
Date: Wed, 3 Jun 2020 14:04:25 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20200603140425.2a4e9d60@simplexum.com>
In-Reply-To: <OyxLj_9i4yfbKGK-W0GXc2V9bQA3RJBPGHmPUz3OtwG6ZMCpRwgXtuFl9E_aDi4M_VP3cNIVoqj3mIjTJ_2rRdGuWyoJcNNCKs2G6znGhck=@protonmail.com>
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
<vtu_ujJwxJDSC3w4QI5VlQ8WfkxaRg1Jk4nSNybgeYSWgGrN7sJiKa9dNzb0tDbRBdVhT4p60v-j6C2F8LmFxMLUTi_VtCznWRb56GVlvu8=@protonmail.com>
<CAPv7TjYePyEt2YMg3J_KinK6Lv6SSLAF2nrOj79_oVt8qBXN0w@mail.gmail.com>
<OyxLj_9i4yfbKGK-W0GXc2V9bQA3RJBPGHmPUz3OtwG6ZMCpRwgXtuFl9E_aDi4M_VP3cNIVoqj3mIjTJ_2rRdGuWyoJcNNCKs2G6znGhck=@protonmail.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 03 Jun 2020 09:34:29 +0000
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: Wed, 03 Jun 2020 09:01:38 -0000
I made a version of the TLA+ spec according to the suggested variant,
as I understood it from your description. This version is in
the separate branch in the SASwap repo, 'variant_ZmnSCPxj' [1]
If I understood and specified your variant correctly, there is a
deadlock possible after step 9, if Bob fails to publish success tx in
time. After refund tx becomes spendable, Alice cannot publish it via
mempool, because Bob can learn her secret and has a chance invalidate
her refund tx by giving his success tx to friendly miner, while taking
back the locked LTC because both secrets are known. At the same time,
Bob cannot publish success tx via mempool, because then Alice can do
the same thing, invalidating his success tx with refund tx via friednly
miner.
There is a possibility that this deadlock can be resolved if one
participant indeed has possibility to confirm their tx directly,
bypassing the mempool, so the counterparty won't learn the secret until
transaction is in the block. But then this just raises the cost of the
attack because the counterparty will need to invalidate (orphan) the
whole block instead of just a transaction in the mempool, after
learning the other secret from the recent block.
[1] https://github.com/dgpv/SASwap_TLAplus_spec/tree/variant_ZmnSCPxj
=D0=92 Tue, 12 May 2020 04:41:43 +0000
ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning Ruben,
>=20
> > Hi ZmnSCPxj,
> >
> > Thanks for your feedback :)
> > =20
> > > CoinSwap for privacy is practically a "cross" chain atomic swap
> > > with the same chain and token for both sides of the swap =20
> >
> > I agree, I didn't mean to imply that was new, only that this
> > protocol makes it more efficient.
> > =20
>=20
> Indeed; basically, any innovations in cross-chain swaps can be
> adapted to a CoinSwap (though not necessarily vice-versa, if a
> CoinSwap innovation requires certain specific blockchain features).
>=20
> > > "Instead, Bob simply hands secretBob to Alice" is basically the
> > > same as private key turnover =20
> >
> > 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
> > =20
>=20
> An interesting setup.
>=20
> So I was wondering why something like this would not work instead:
>=20
> 0. Alice has BTC, Bob has LTC, they agree on exchange rates and two
> future timelock L1 and L2 such that L1 < L2. 1. Alice creates
> keypairs Alice[0] Alice[1] Alice[2], Bob creates Bob[0] Bob[1]
> Bob[2], and share the pubkeys. 2. Alice creates, but does not sign,
> a funding tx on BTC whose output requires Alice[0] && Bob[0]. 3. Bob
> creates a backout transaction spending the BTC funding txo, with an
> absolute timelock L1, whose output goes to Alice[2], then provides to
> Alice a signature for Bob[0] and requires an adaptor such that
> completing the signature with Alice[0] reveals Alice[1].
>=20
> nLockTime L1
> BTC funding txo ---> Alice[0] && Bob[0] ---> Alice[2]
> reveals Alice[1]
>=20
> 4. Alice creates a timeout transaction spending the BTC funding txo,
> with an absolute timelock L2, whose output goes to Bob[2], then
> provides to Bob a signature for Alice[0] and requires an adaptor such
> that completing the signature with Bob[0] reveals Bob[1].
>=20
> nLockTime L2
> BTC funding txo ---> Alice[0] && Bob[0] ---> Bob[2]
> reveals Bob[1]
>=20
> 5. Alice signs the BTC funding tx and broadcasts it.
> 6. Alice and Bob wait for the BTC funding tx to be confirmed.
> 7. Bob creates an LTC funding tx whose output requires Alice[1] &&
> Bob[1]. 8. Alice and Bob wait for the LTC funding tx to be confirmed.
> 9. Alice creates a success transaction spending the BTC funding txo,
> with no practical absolute timelock (current blockheight + 1), whose
> output goes to Bob[2], then provides to Bob a signature for Alice[0]
> and requires an adaptor such that completing the signature with
> Bob[0] reveals Bob[1].
>=20
> nLockTime now
> BTC funding txo ---> Alice[0] && Bob[0] ---> Bob[2]
> reveals Bob[1]
>=20
> 10. Bob gives the secret key of Bob[1] to Alice.
> 11. Alice gives the secret key of Alice[0] to Bob.
> 12. Bob claims the BTC funding txo before L1.
>=20
> Aborts and stalls:
>=20
> * Aborts before step 5 are safe: no money is ever committed yet.
> Stalls before step 5 can be promoted to aborts.
> * If aborted between step 5 and step 8, Alice reclaims her BTC via
> the backout transaction. Since Bob did not confirm any locked funds
> in LTC, revealing Alice[1] does not give Bob any extra funds it did
> not already have. If Bob stalls before step 8 Alice can abort at L1
> using the backout transaction.
> * If Alice stalls at step 9, Bob can force the completion using the
> timeout transaction at L2, revealing Bob[1] and claiming the BTC.
> * If Alice instead aborts at step 9 using the backout transaction at
> L1, Bob learns Alice[1] and can reclaim its LTC.
> * Steps 10 and 11 are optional and "only" give Alice and Bob extra
> flexibility in what they can do with the funds (such as sweeping
> multiple swaps, RBFing, performing another swap, etc.), i.e. private
> key turnover. Bob can always claim the BTC funding txo before L1 by
> signing and broadcasting the success transaction.
>=20
> Would this not work?
> It requires that at least one chain involved supports witness
> segregation, in order to allow signing a dependent transaction before
> signing what it spends.
>=20
> This has the advantage of using only absolute timelocks, which are
> better for privacy since ordinary wallets like Bitcoin Core and
> C-Lightning use absolute timelocks for ordinary spends onchain.
>=20
>=20
> >
> > 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. =20
>=20
>=20
> If the above counterproposal would work, it seems to me that all
> abort and stall scenarios "just" involve an absolute-timelock
> `SIGHASH_ALL` signed transaction, so it might not be so inevitable.
>=20
> In addition, the above counterproposal has the transaction signatures
> be completed by whoever ends up getting the money, so will rationally
> use the version with the best feerate.
>=20
> While leaking information in case of uncooperative abort is
> acceptable, it still seems to me that in this case, we can have a
> solution where an uncooperative abort has no information leak. My
> thesis is that, if relative locktimes are used as often as absolute
> locktimes for block-sniping-prevention and a decent Scriptless Script
> system, then all protocol aborts should be doable with no information
> leaks, at the cost of pre-signing a bunch of timelocked transactions.
>=20
> ---
>=20
> A sidenote as well, that if Alice typically uses an HD wallet, the
> UTXO on the LTC side would not be in that HD, and if Alice wants to
> cold-store the LTC, it should move the money as well into an HD
> pubkey.
>=20
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
