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
|
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 A571AC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 May 2020 04:41:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 9B09888306
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 May 2020 04:41:57 +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 HOB4s+6dxUOE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 May 2020 04:41:55 +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 hemlock.osuosl.org (Postfix) with ESMTPS id 65942882C4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 May 2020 04:41:55 +0000 (UTC)
Date: Tue, 12 May 2020 04:41:43 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1589258513;
bh=ybD4v12zupaEjLtiver0sCF0k7UYBQNYEeOMOveRTp0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=XLMyInhQmwyKQawsaKyzjPKoIKi6s3AU9nMcyXoVPVzoFY8Rt638sqnw+8bCsL4/O
huCR1NxioaQLiIiGQAfw/kfSMnfgS8aXhkrg3KkXx4qrImhqHLqzxVeW4am7yezWW1
7/5n1wlNw2RwVXvi3ZJsNrWSqf9nnvwWH5oQBsxA=
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <OyxLj_9i4yfbKGK-W0GXc2V9bQA3RJBPGHmPUz3OtwG6ZMCpRwgXtuFl9E_aDi4M_VP3cNIVoqj3mIjTJ_2rRdGuWyoJcNNCKs2G6znGhck=@protonmail.com>
In-Reply-To: <CAPv7TjYePyEt2YMg3J_KinK6Lv6SSLAF2nrOj79_oVt8qBXN0w@mail.gmail.com>
References: <CAPv7TjZGBbf6f1y49HLFD2eNiP5d4e+=dFGqiMFs6jaeYyH-NQ@mail.gmail.com>
<vtu_ujJwxJDSC3w4QI5VlQ8WfkxaRg1Jk4nSNybgeYSWgGrN7sJiKa9dNzb0tDbRBdVhT4p60v-j6C2F8LmFxMLUTi_VtCznWRb56GVlvu8=@protonmail.com>
<CAPv7TjYePyEt2YMg3J_KinK6Lv6SSLAF2nrOj79_oVt8qBXN0w@mail.gmail.com>
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] 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: Tue, 12 May 2020 04:41:57 -0000
Good morning Ruben,
> Hi ZmnSCPxj,
>
> Thanks for your feedback :)
>
> > CoinSwap for privacy is practically a "cross" chain atomic swap with th=
e same 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.
>
Indeed; basically, any innovations in cross-chain swaps can be adapted to a=
CoinSwap (though not necessarily vice-versa, if a CoinSwap innovation requ=
ires certain specific blockchain features).
> > "Instead, Bob simply hands secretBob to Alice" is basically the same as=
private 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
>
An interesting setup.
So I was wondering why something like this would not work instead:
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] B=
ob[1] Bob[2], and share the pubkeys.
2. Alice creates, but does not sign, a funding tx on BTC whose output requ=
ires 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 Alic=
e a signature for Bob[0] and requires an adaptor such that completing the s=
ignature with Alice[0] reveals Alice[1].
nLockTime L1
BTC funding txo ---> Alice[0] && Bob[0] ---> Alice[2]
reveals Alice[1]
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 s=
ignature with Bob[0] reveals Bob[1].
nLockTime L2
BTC funding txo ---> Alice[0] && Bob[0] ---> Bob[2]
reveals Bob[1]
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 a=
daptor such that completing the signature with Bob[0] reveals Bob[1].
nLockTime now
BTC funding txo ---> Alice[0] && Bob[0] ---> Bob[2]
reveals Bob[1]
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.
Aborts and stalls:
* 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 back=
out transaction.
Since Bob did not confirm any locked funds in LTC, revealing Alice[1] doe=
s 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 trans=
action.
* 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, Bo=
b learns Alice[1] and can reclaim its LTC.
* Steps 10 and 11 are optional and "only" give Alice and Bob extra flexibil=
ity in what they can do with the funds (such as sweeping multiple swaps, RB=
Fing, performing another swap, etc.), i.e. private key turnover.
Bob can always claim the BTC funding txo before L1 by signing and broadca=
sting the success transaction.
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 sp=
ends.
This has the advantage of using only absolute timelocks, which are better f=
or privacy since ordinary wallets like Bitcoin Core and C-Lightning use abs=
olute timelocks for ordinary spends onchain.
>
> 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.
If the above counterproposal would work, it seems to me that all abort and =
stall scenarios "just" involve an absolute-timelock `SIGHASH_ALL` signed tr=
ansaction, so it might not be so inevitable.
In addition, the above counterproposal has the transaction signatures be co=
mpleted by whoever ends up getting the money, so will rationally use the ve=
rsion with the best feerate.
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 uncoop=
erative abort has no information leak.
My thesis is that, if relative locktimes are used as often as absolute lock=
times for block-sniping-prevention and a decent Scriptless Script system, t=
hen all protocol aborts should be doable with no information leaks, at the =
cost of pre-signing a bunch of timelocked transactions.
---
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.
Regards,
ZmnSCPxj
|
