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
|
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 61777C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 May 2020 05:31:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 25D26221B5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 May 2020 05:31:30 +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 g0Wht8ZjuM8H
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 May 2020 05:31:28 +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 570EF20467
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 14 May 2020 05:31:28 +0000 (UTC)
Received: by mail-ed1-f54.google.com with SMTP id g9so1336405edr.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 May 2020 22:31:28 -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; bh=Eema8aaBs70VBa3ijyD9CG/XMQzE6vONIx3B4TiHlS0=;
b=NCZafi68yXwQRUSD5PteoYN7sUMC6WD9hVr1gkw9Mz3Dbvqrnn3xbhwfyHEs5IYfnt
2mclbyy3xZyRMJyImeQOjHYmCzihpLCIVFDTJCUst3W5YiHmBf2Za6esC9L/a6NfGMRw
eTIFh8+d1nJQshOPZ7T7PvnXAcWnrKf8Ltsx9NMrI1Ehz+AhSM9XyaNW3Hcs5ejwd8//
mfoDQkj0kN1ZZG8b5PE3yUzRQUITYKlJPzBCv/pAzVwUlCfeKbes96mkC1NHfnyPiwWi
FvA6ZqY5LaZzvZq3er0ZVKE1wigvwTD84iTLg4N7EDbedD+rPINrFKZU38e5P2s00I6b
5xPw==
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;
bh=Eema8aaBs70VBa3ijyD9CG/XMQzE6vONIx3B4TiHlS0=;
b=copAWppxaLxwpiKR1EVHbznXthoBd01UBzM/KLXqg/cEILDihNAjkB3x5OXOElR0tn
4FWRRnBHE6xRPdeQbUikIp09eZjBc3IWDchHJnDdYURxtfRjj9UkT+Ong9USDbbNYFrB
Ayz9Dmr+wSJLuF1yfQGan3qWraSv/05Re4/VDJdkgxVkCSlefJx9RdTr9Lo53q+fbuX3
UhIU1Mwe2c4pCoWjJ/jQv8V4zV5FW9FJaHTmX17pqgXYeT1DQtg2bX51kmZNiOVbrCcc
JTTaSGfVTq4qwnTRq1HA0HyTSlzp5UsTaOIzqiK1v4QEkviMSs2FmmiO5fsWow86uewM
E8Aw==
X-Gm-Message-State: AOAM532knfSI9J/6BpAAYcgm/b/gKGEcJeGFamkIrE2nz/tzanxK1i4i
DVks9LiLVjOjzQPreOx8tSWiurS4zqTsgLzWDig=
X-Google-Smtp-Source: ABdhPJwRJr+/F3MDGzEvjHbYEs4L7RNFpF1IoxBt+u1Z6eziEeXNy4i7v9ovV7TnpOya45VPErqkReWxGmel8k216TM=
X-Received: by 2002:a05:6402:30b4:: with SMTP id
df20mr2488234edb.158.1589434286726;
Wed, 13 May 2020 22:31:26 -0700 (PDT)
MIME-Version: 1.0
References: <20200513220222.24953c0a@simplexum.com>
<CAPv7TjbZVYTztQLd2dxjzFajhPTg23iWtapkVBzz+z0q=pH2rw@mail.gmail.com>
<20200514095215.4ea20666@simplexum.com>
In-Reply-To: <20200514095215.4ea20666@simplexum.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Thu, 14 May 2020 07:31:13 +0200
Message-ID: <CAPv7TjYY+kKHM6qzM9WKU7rB5J=RE_oaaW1XcM1Jr+ap=-pJOg@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="0000000000000ddfd505a59502db"
X-Mailman-Approved-At: Thu, 14 May 2020 05:32:11 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] TLA+ specification for Succint 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: Thu, 14 May 2020 05:31:30 -0000
--0000000000000ddfd505a59502db
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Dmitry,
>While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly
miner
I see, so you're talking about prior to protocol completion, right after
Alice sends Bob the success_tx. The reason this is not an issue is because
Alice and Bob both had to misbehave in order for this to happen. Bob is
misbehaving here because he should have published the success_tx before
refund_tx_1 became valid, and Alice is misbehaving here because she should
have sent the revoke_tx (which invalidates the success_tx) followed by
refund_tx_2 (revealing her secret only AFTER Bob can no longer claim the
BTC). In other words: yes, the protocol can fail if Alice and Bob together
work towards that goal. A feature, not a bug. This won't happen if either
of them doesn't want it to. I imagine this is difficult to model.
>As I understand, this is a way to deny Alice to use refund_tx_1.
That is correct, and it also denies refund_tx_2 by making the revoke_tx
directly spendable by Bob.
>could Bob just spend the Alice&Bob output of the very first, "commitment"
transaction that locks BTC
Yes, he can. This is what makes it possible to complete the protocol in
merely two transactions.
>Bob will receive BTC, and the LTC can be locked forever, but Bob doesn't
care, he got his BTC.
No, because diagram step 5 comes before step 6 -- Alice won't give her key
until she learns secretBob.
I hope this clarifies it!
Cheers,
Ruben
On Thu, May 14, 2020 at 6:49 AM Dmitry Petukhov <dp@simplexum.com> wrote:
> =D0=92 Wed, 13 May 2020 21:03:17 +0200
> Ruben Somsen <rsomsen@gmail.com> wrote:
>
> > Or perhaps you're referring to the issue ZmnSCPxj pointed out after
> > that, where refund transaction #1 and the success transaction could
> > both become valid at the same time. It would make sense for the test
> > to pick up on that, but I believe that is ultimately also not an
> > issue (see my last reply in the thread).
>
> This one.
>
> The issue as I see it: Bob can not broadcast success_tx and wait until
> Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,
> Bob gives success_tx to the friendly miner to have a chance to
> invalidate success_tx. Bob already learned secretAlice, so he grabs
> his LTC back. If the Bob-friendly miner has luck, success_tx is
> confirmed while refund_tx_1 is invalidated, and Bob now have both LTC
> and BTC, while Alice is out of her BTC.
>
> > >I did not understand what the destination of Alice&Bob cooperative
> > >spend
> > of refund_tx#1 will be
> >
> > This transaction can be spent by Alice & Bob right away or by Alice a
> > day later (in relative time, so the tx has to confirm first). The
> > Alice & Bob condition is there purely to ensure that Bob can spend
> > the money before Alice once he receives her key at the end of the
> > protocol.
>
> Ah, so this is possible because of the step 5 in the diagram: ``Alice
> gives Bob her key ("Alice")'' -- As I understand, this is a way to deny
> Alice to use refund_tx_1.
>
> Then if Alice gives her _key_ to Bob before Bob has to share secretBob
> via success_tx, could Bob just spend the Alice&Bob output of the
> very first, "commitment" transaction that locks BTC ? Bob will receive
> BTC, and the LTC can be locked forever, but Bob doesn't care, he got
> his BTC.
>
--0000000000000ddfd505a59502db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Dmitry,<div><br></div><div>>While refund_tx_1 is in =
the mempool, Bob gives success_tx to the friendly miner</div><div><br></div=
><div>I see, so you're talking about prior to protocol completion, righ=
t after Alice sends Bob the success_tx. The reason this is not an issue is =
because Alice and Bob both had to misbehave in order for this to happen. Bo=
b is misbehaving here because he should have published the success_tx befor=
e refund_tx_1 became valid, and Alice is misbehaving here because she shoul=
d have sent the revoke_tx (which invalidates the success_tx) followed by re=
fund_tx_2 (revealing her secret only AFTER Bob can no longer claim the BTC)=
. In other words: yes, the protocol can fail if Alice and Bob together work=
towards that goal. A feature, not a bug. This won't happen if either o=
f them doesn't want it to. I imagine this is difficult to model.</div><=
div><br></div><div>>As I understand, this is a way to deny Alice to use =
refund_tx_1.<br></div><div><br></div><div>That is correct, and it also deni=
es refund_tx_2 by making the revoke_tx directly spendable by Bob.</div><div=
><br></div><div>>could Bob just spend the Alice&Bob output of the ve=
ry first, "commitment" transaction that locks BTC</div><div><br><=
/div><div>Yes, he can. This is what makes it possible to complete the proto=
col in merely two transactions.</div><div><br></div><div>>Bob will recei=
ve BTC, and the LTC can be locked forever, but Bob doesn't care, he got=
his BTC.</div><div><br></div><div>No, because diagram step 5 comes before =
step 6 -- Alice won't give her key until she learns secretBob.</div><di=
v><br></div><div>I hope this clarifies it!</div><div><br></div><div>Cheers,=
</div><div>Ruben</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
class=3D"gmail_attr">On Thu, May 14, 2020 at 6:49 AM Dmitry Petukhov <<=
a href=3D"mailto:dp@simplexum.com">dp@simplexum.com</a>> wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">=D0=92 Wed, 13 May 2020 =
21:03:17 +0200<br>
Ruben Somsen <<a href=3D"mailto:rsomsen@gmail.com" target=3D"_blank">rso=
msen@gmail.com</a>> wrote:<br>
<br>
> Or perhaps you're referring to the issue ZmnSCPxj pointed out afte=
r<br>
> that, where refund transaction #1 and the success transaction could<br=
>
> both become valid at the same time. It would make sense for the test<b=
r>
> to pick up on that, but I believe that is ultimately also not an<br>
> issue (see my last reply in the thread).<br>
<br>
This one.<br>
<br>
The issue as I see it: Bob can not broadcast success_tx and wait until<br>
Alice has broadcasted refund_tx_1. While refund_tx_1 is in the mempool,<br>
Bob gives success_tx to the friendly miner to have a chance to<br>
invalidate success_tx. Bob already learned secretAlice, so he grabs<br>
his LTC back. If the Bob-friendly miner has luck, success_tx is<br>
confirmed while refund_tx_1 is invalidated, and Bob now have both LTC<br>
and BTC, while Alice is out of her BTC.<br>
<br>
> >I did not understand what the destination of Alice&Bob coopera=
tive<br>
> >spend=C2=A0 <br>
> of refund_tx#1 will be<br>
> <br>
> This transaction can be spent by Alice & Bob right away or by Alic=
e a<br>
> day later (in relative time, so the tx has to confirm first). The<br>
> Alice & Bob condition is there purely to ensure that Bob can spend=
<br>
> the money before Alice once he receives her key at the end of the<br>
> protocol.<br>
<br>
Ah, so this is possible because of the step 5 in the diagram: ``Alice<br>
gives Bob her key ("Alice")'' -- As I understand, this is=
a way to deny<br>
Alice to use refund_tx_1.<br>
<br>
Then if Alice gives her _key_ to Bob before Bob has to share secretBob<br>
via success_tx, could Bob just spend the Alice&Bob output of the<br>
very first, "commitment" transaction that locks BTC ? Bob will re=
ceive<br>
BTC, and the LTC can be locked forever, but Bob doesn't care, he got<br=
>
his BTC.<br>
</blockquote></div>
--0000000000000ddfd505a59502db--
|
