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
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
|
Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DBF3DB88
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 09:22:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com
[209.85.210.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5CD5B87D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 09:22:58 +0000 (UTC)
Received: by mail-ot1-f66.google.com with SMTP id j7so11580132ota.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 02:22:58 -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=u5BUTdkh1l1v8dDCr3t6o1rokJajQkxWkLXKEdzu1dg=;
b=XSZcD2p+cAL8LCvYIm1E1tdUPgsC7XU8evZQ2Be5bBqogx0XFOtA8V8TuQG8VIUQj8
2Iue1XNz0yT0JZ0kw39/IF1bD7aE3iKAltQTijZC9Y6kIVr5Lg/jrns6tJfCcUExkd6C
beEv4Z0gab1+cvY2at8NyC8aNXgGOHM4xoXKsZKC8oxpXhCn/ugYX9zKvYXn0YXxuEnf
bjfB53zAWDaBF+OXjwPnMAbnFDv7yZSYJ+EaH/pLXsvj1GTZDDqXerNGBSv+oGw/rVxI
OKsK2lglMVYrGSBd8e/Ez4WSDazPrKwZVRSYkt8t3z4g/kJxMl9nMTB/B1cBF6mnOd0+
YcMQ==
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=u5BUTdkh1l1v8dDCr3t6o1rokJajQkxWkLXKEdzu1dg=;
b=EVjSbYnQk6CIXnSq3ebMXhrmwvMQP8xd9l8LAOW3cBmAtxkDL4NhWlPcQiimRO+H5R
MUYcUP5WWPsDU7mg4Lu3B3zu/ggrysuo5z5i5g9Gv/Hkkjhv8YraweE1lB/B9h2s1r+B
vAMnv1fPoH50P6T4c61csg64XDiTjqro24BS4TFxTNIXvQB7xVGGp06k1KRVZRtJhZaF
VMu75J77h3jU/62dhz0y5mfdZuWoYIS7o1274b7QCepVMbvCytS1/YsVD/YnPGjP0S4v
XyvV63kD8MmEhBee/UAtxgnihBbjAaHSSR9hAIXIuZJSuvGdNLw1KXRptCFq71AmCTik
UZ6A==
X-Gm-Message-State: APjAAAXkCi8stAyRHDeALfExs3OgTMmOb33fvfqWtxcvOqs92iDQ0uKg
SOhjhbeJByqnY2u3uLBEBekdQ5RLi4wrFX0ZDug=
X-Google-Smtp-Source: APXvYqwIseqePg6tpNThZtiXeUPsEz7Wl5zC3XR9qPf+uLqkpEE6kxmvNqwESrjp62McTIA7Y7jRNfzuCImbBuxU1sI=
X-Received: by 2002:a6b:c581:: with SMTP id
v123mr13462082iof.158.1565601777412;
Mon, 12 Aug 2019 02:22:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com>
<qBFyALsLsiKkSXsssc3T7dvwrXtzBXmAAmTFWAt04AkrFwbWnoCdGIjoyqMZGnJa5Y4CX5mi0-1uWtuzPT5Swr3txw6NthtkOUdzCOlyfXo=@protonmail.com>
<ADA03200-1EED-4EAD-B320-3F2034F00954@monash.edu>
<aJ7usJIj2_reg-36SKEUDRApK8AhsIm2esl-I1CJSxs8cZACAmuR0X1bBNDK_zlDOUlzUWD2n2pCnbYx20Jg8kvAyryKZ9mqe0OH2J0QivY=@protonmail.com>
<CABnocSBSKsmWeRCOZE6DHwPXc2rucQGkHvjd+wJ+9JAJOT5=QQ@mail.gmail.com>
<212E8AD5-0EED-468E-8AFC-134611514CBC@monash.edu>
<OLQmXBBI4kc9mkjbpr92bKp3UFhmg7ZtTn-m_VNinXNDT4CYz9Jf45gpSfxmkzXQLJfchMk7AaqEjbEor-ZJ02xrd_0yb2MOekXfRyovj6U=@protonmail.com>
In-Reply-To: <OLQmXBBI4kc9mkjbpr92bKp3UFhmg7ZtTn-m_VNinXNDT4CYz9Jf45gpSfxmkzXQLJfchMk7AaqEjbEor-ZJ02xrd_0yb2MOekXfRyovj6U=@protonmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Mon, 12 Aug 2019 17:22:29 +0800
Message-ID: <CAH5Bsr0rfHVnwcaHq_hpU4Wiz6AZ12kwDstJ34s3K7w=o-4azQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cd6dd6058fe81133"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 13 Aug 2019 02:14:16 +0000
Cc: "jiangshan.yu@monash.edu" <jiangshan.yu@monash.edu>,
Runchao Han <runchao.han@monash.edu>
Subject: Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 12 Aug 2019 09:23:00 -0000
--000000000000cd6dd6058fe81133
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello Runchao and ZmnSCPxj,
I think we can simplify the explanation here by not using joint signatures
and payment channel like constructions. ZmnSCPxj's more complex
construction could be more dynamic and practical in some settings but at
least for me it gets in the way of capturing how this relatively simple
idea works.
Here's my attempt at distilling the idea:
Step 0: Alice and Bob negotiate the parameters (timeouts, refund/redeem
pubkeys, the collateral amounts and inputs/outputs for the WTJ-HTLC)
=3D=3D=3D Step 1 =3D=3D=3D
Alice signs and broadcasts the BTC-HTLC and sends signature(s) on her
input(s) to the WJT-HLTC to Bob.
Note:
1. She does not need to wait for the BTC-HTLC to confirm before she sends
her signature(s).
2. There is no benefit to Alice in delaying at this point
=3D=3D=3D Step 2 =3D=3D=3D
Upon receiving Alice's input signature(s) and seeing the BTC-HTLC with
sufficient confirmations, Bob completes the transaction by supplying his
own signature(s) and broadcasts it.
Note:
1. Bob's ability to delay at this point shouldn't be considered an option.
Alice may withdraw her offer by double spending her one of her inputs to
the WTJ-HTLC. Alice's ability to cancel the offer and take back BTC after
the timeout proves there is no option (options cannot be cancelled)
2. In this plain construction Alice should cancel promptly (if she doesn't
see the WTJ-HTLC within the next 1 or 2 blocks for example)
3. You could even extend this protocol to specify that Bob send signatures
on his inputs the WTJ-HTLC immediately to Alice. If he refuses Alice can
cancel within a second or two.
=3D=3D=3D Step 3 =3D=3D=3D
Upon seeing the WTJ-HTLC get sufficient confirmations, Alice takes the
funds (including her collateral back) by revealing the secret.
Note:
1. If she doesn't redeem the HTLC she loses her collateral. Assuming the
loss of the collateral overwhelms any gain she could experience from the
delaying her decision and she operates in her own financial interest she
redeems it immediately.
Step 4 is as usual.
At each step there is no unfair advantage to either party (at least if we
idealise the blockchains somewhat and assume that neither party can
influence which transactions get into which block etc etc).
ZmnSCPxj,
Thanks for continuing to spread this idea!
I'm still not sure about your "two hashes" approach to lightning but I hope
to get to the bottom of it soon by describing how I think it should work
more formally somewhere. Will post to lightning-dev when I do :)
LL
On Mon, Aug 12, 2019 at 4:06 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good morning Runchao,
>
>
> Sent with ProtonMail Secure Email.
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Monday, August 12, 2019 11:19 AM, Runchao Han <runchao.han@monash.edu>
> wrote:
>
> > Good morning ZmnSCPxj,
> >
> > Sorry for the ambiguity of my last email. It was Sunday and I wrote it
> in 1 min on my bed. Let me elaborate what we are thinking of here.
> >
> > ## Analysis on the protocol from Fournier et al.
> >
> > In this protocol, Bob participates in the swap following the steps belo=
w:
> >
> > 1. Alice and Bob creates a payment channel on WJT blockchain.
> > 2. Bob creates the WJT transaction using the joint account of Alice and
> Bob, including 1) Bob's input of 1,000,000 WJT, 2) Alice=E2=80=99s input =
for the
> 10,000 WJT premium. This transaction should be signed by both Alice and B=
ob
> in order to be valid.
> > 3. Bob signs the WJT transaction and sends the WJT transaction to Alice=
.
> > 4. Alice signs this WJT transaction. At this stage, Alice has both the
> valid BTC transaction and the valid WJT transaction.
> > 5. Alice broadcasts both the BTC transaction and the WJT transaction.
>
> Incorrect.
>
> The order is below.
> I add also the behavior when the protocol is stalled such that a step is
> not completed.
>
> 1. Alice broadcasts and confirms a BTC transaction paying an HTLC,
> hashlock Bob, Timelock Alice.
> * Alice is initiating the protocol via this step, thus non-completion
> of this step is simply not performing the protocol.
> 2. Alice informs the BTC transaction to Bob.
> * If Alice does not perform this, Bob does not know it and Alice
> locked her own money for no reason.
> 3. Alice and Bob indicate their inputs for the WJT-side funding
> transaction.
> * If Alice does not perform this, it aborts the protocol and Alice
> locked her own money for no reason.
> * If Bob does not perform this, it aborts the protocol and Bob turns
> down the opportunity to earn 10,000 WJT (opportunity cost).
> 4. Alice and Bob exchange signatures for the WJT-side claim transaction
> which spends the funding transaction via the hashlock side and gives
> 1,000,000 WJT to payout to Alice and 10,000 WJT premium to Bob.
> Order does not matter as funding tx is still unsigned.
> * If Alice does not perform this, it aborts the protocol and Alice
> locked her own money for no reason.
> * If Bob does not perform this, it aborts the protocol and Bob turns
> down the opportunity to earn 10,000 WJT (opportunity cost).
> 5. Bob provides signatures for the WJT funding tx,
> * If Bob does not perform this, it aborts the protocol and Bob turns
> down the opportunity to earn 10,000 WJT (opportunity cost).
> 6. Alice signs WJT funding tx and broacasts and confirms.
> * If Alice does not perform this, Bob invalidates the transaction by
> spending any of his inputs.
> * Alice has an option here, but a very short option: up until Bob
> grows tired of waiting.
> Bob can make this timeout arbitrarily small, without requiring
> input from Alice.
> What value would there be in a 1-second option, even gotten for
> free, when Alice has spent fees on the BTC-side transaction in the first
> place?
> 7. Alice completes the claim transaction and broadcasts.
> * If Alice does not perform this, Bob simply waits out the timelock
> and recovers his funds plus premium.
> 8. Bob spends the BTC HTLC via the hashlock path.
> * If Bob does not perform this, Bob has given money for free to Alice=
.
>
> Thus I do not believe this is needed for blockchain-layer atomic swaps.
>
> For Lightning-layer atomic swaps, the solution requires that two hashes b=
e
> used on the WJT side, and is largely the above protocol in very broad
> strokes.
> Unfortunately, using two hashes instead of one leaks to intermediate hops
> that the payment involved a cross-currency swap, thus undesirable.
>
>
>
> >
> > In a word, Bob is responsible for preparing the WJT transaction, while
> Alice is responsible for preparing the BTC transaction and broadcasting
> both transactions.
> >
> > Here, if Bob stalls, nothing will happen, because Bob cannot spend the
> 10,000 WJT premium without Alice=E2=80=99s signature.
> > If Alice stalls, you are saying that Bob can spend the input of
> 1,000,000 WJT so he does not lose any money.
> >
> > I have 3 questions on this scheme.
> >
> > First, I=E2=80=99m not sure how do you define =E2=80=9CAlice stalls=E2=
=80=9D. In this case,
> Alice can stall by 1) withhold the WJT tx, or 2) broadcast BTC/WJT fundin=
g
> txs but withhold the preimage.
> > If 2), this protocol is okay. But what about 1) i.e. Alice withholds th=
e
> WJT tx? Here, Bob cannot do anything except for closing the payment chann=
el
> and quit.
>
> Yes.
>
> >
> > Second, I=E2=80=99m not sure whether Bob can spend his money in this pa=
yment
> channel while the payment channel is still valid.
> > In Bitcoin, Bob needs to close the payment channel and get back his
> money first, then he can spend the money.
>
> Depends on how the payment channel is implemented.
> If you do something like send transactions spending the internal state
> outputs, then ratifying this later by performing a transaction cut-throug=
h
> to derive the next state update, then it is no different from blockchain
> layer.
> Of course, if you postulate the non-cooperation of Alice in this, there i=
s
> indeed a need to close unilaterally.
> But this is the same as any non-cooperation in any channel system: that i=
s
> the entire point why you have unilateral closes.
>
> >
> > Third, let=E2=80=99s optimistically assume Bob can close this payment c=
hannel
> without Alice=E2=80=99s consent.
>
> Every payment channel system worth consideration today has a unilateral
> close.
> There is no need for optimism.
>
> > Now he decides to close this channel if Alice does not broadcast the WJ=
T
> tx all the time.
> > Alice does not need to pay for the premium if she withholds the WJT tx.
> If Alice decides not to proceed this swap, Bob should close this channel
> and get back 1,000,000 WJT. However, Bob cannot get the 10,000 WJT premiu=
m.
>
> And this time frame can be made arbitarily small by Bob by simple threat
> of unilateral close, thus not making it an option for Alice.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000cd6dd6058fe81133
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello Runchao and=C2=A0ZmnSCPxj,<div><br></div><div>I thin=
k we can simplify the explanation here by not using joint signatures and pa=
yment channel like constructions. ZmnSCPxj's more complex construction =
could be more dynamic and practical in some settings but at least for me it=
gets in the way of capturing how this relatively simple idea works.</div><=
div>Here's my attempt at distilling the idea:</div><div><br></div><div>=
<div>Step 0: Alice and Bob negotiate the parameters (timeouts, refund/redee=
m pubkeys, the collateral amounts and inputs/outputs for the WTJ-HTLC)</div=
><br class=3D"gmail-m_7969490660491870304gmail-Apple-interchange-newline"><=
/div><div>=3D=3D=3D Step 1 =3D=3D=3D</div><div>=C2=A0Alice signs and broadc=
asts the BTC-HTLC and sends signature(s) on her input(s) to the WJT-HLTC to=
Bob.<br></div><div>Note:</div><div>1. She does not need to wait for the BT=
C-HTLC to confirm before she sends her signature(s).</div><div>2. There is =
no benefit to Alice in delaying at this point</div><div><br></div><div>=3D=
=3D=3D Step 2 =3D=3D=3D</div><div>Upon receiving Alice's input signatur=
e(s) and seeing the BTC-HTLC with sufficient confirmations, Bob completes t=
he transaction by supplying his own signature(s) and broadcasts it.</div><d=
iv><br></div><div>Note:</div><div>1. Bob's ability to delay at this poi=
nt shouldn't be considered an option. Alice may withdraw her offer by d=
ouble spending her one of her inputs to the WTJ-HTLC. Alice's ability t=
o cancel the offer and take back BTC after the timeout proves there is no o=
ption (options cannot be cancelled)</div><div>2. In this plain construction=
Alice should cancel promptly (if she doesn't see the WTJ-HTLC within t=
he next 1 or 2 blocks for example)</div><div>3. You could even extend this =
protocol=C2=A0 to specify that Bob send signatures on his inputs the WTJ-HT=
LC immediately to Alice. If he refuses Alice can cancel within a second or =
two.</div><div><br></div><div>=3D=3D=3D Step 3 =3D=3D=3D</div><div>Upon see=
ing the WTJ-HTLC get sufficient confirmations, Alice takes the funds (inclu=
ding her collateral back) by revealing the secret.</div><div><br></div><div=
>Note:</div><div>1. If she doesn't redeem the HTLC she loses her collat=
eral. Assuming the loss of the collateral overwhelms any gain she could exp=
erience from the delaying her decision and she operates in her own financia=
l interest she redeems it immediately.</div><div><br></div><div>Step 4 is a=
s usual.</div><div><br></div><div>At each step there is no unfair advantage=
to either party (at least if we idealise the blockchains somewhat and assu=
me that neither party can influence which transactions get into which block=
etc etc).</div><div><br></div><div>ZmnSCPxj,<br></div><div><br></div><div>=
Thanks for continuing to spread this idea!</div><div>I'm still not sure=
about your "two hashes" approach to lightning but I hope to get =
to the bottom of it soon by describing how I think it should work more form=
ally somewhere. Will post to lightning-dev when I do :)</div><div><br></div=
><div>LL</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, Aug 12, 2019 at 4:06 PM ZmnSCPxj via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">Good morning Runchao,<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br>
On Monday, August 12, 2019 11:19 AM, Runchao Han <<a href=3D"mailto:runc=
hao.han@monash.edu" target=3D"_blank">runchao.han@monash.edu</a>> wrote:=
<br>
<br>
> Good morning ZmnSCPxj,<br>
><br>
> Sorry for the ambiguity of my last email. It was Sunday and I wrote it=
in 1 min on my bed. Let me elaborate what we are thinking of here.<br>
><br>
> ## Analysis on the protocol from Fournier et al.<br>
><br>
> In this protocol, Bob participates in the swap following the steps bel=
ow:<br>
><br>
> 1. Alice and Bob creates a payment channel on WJT blockchain.<br>
> 2. Bob creates the WJT transaction using the joint account of Alice an=
d Bob, including 1) Bob's input of 1,000,000 WJT, 2) Alice=E2=80=99s in=
put for the 10,000 WJT premium. This transaction should be signed by both A=
lice and Bob in order to be valid.<br>
> 3. Bob signs the WJT transaction and sends the WJT transaction to Alic=
e.<br>
> 4. Alice signs this WJT transaction. At this stage, Alice has both the=
valid BTC transaction and the valid WJT transaction.<br>
> 5. Alice broadcasts both the BTC transaction and the WJT transaction.<=
br>
<br>
Incorrect.<br>
<br>
The order is below.<br>
I add also the behavior when the protocol is stalled such that a step is no=
t completed.<br>
<br>
1.=C2=A0 Alice broadcasts and confirms a BTC transaction paying an HTLC, ha=
shlock Bob, Timelock Alice.<br>
=C2=A0 =C2=A0 * Alice is initiating the protocol via this step, thus non-co=
mpletion of this step is simply not performing the protocol.<br>
2.=C2=A0 Alice informs the BTC transaction to Bob.<br>
=C2=A0 =C2=A0 * If Alice does not perform this, Bob does not know it and Al=
ice locked her own money for no reason.<br>
3.=C2=A0 Alice and Bob indicate their inputs for the WJT-side funding trans=
action.<br>
=C2=A0 =C2=A0 * If Alice does not perform this, it aborts the protocol and =
Alice locked her own money for no reason.<br>
=C2=A0 =C2=A0 * If Bob does not perform this, it aborts the protocol and Bo=
b turns down the opportunity to earn 10,000 WJT (opportunity cost).<br>
4.=C2=A0 Alice and Bob exchange signatures for the WJT-side claim transacti=
on which spends the funding transaction via the hashlock side and gives 1,0=
00,000 WJT to payout to Alice and 10,000 WJT premium to Bob.<br>
=C2=A0 =C2=A0 Order does not matter as funding=C2=A0 tx is still unsigned.<=
br>
=C2=A0 =C2=A0 * If Alice does not perform this, it aborts the protocol and =
Alice locked her own money for no reason.<br>
=C2=A0 =C2=A0 * If Bob does not perform this, it aborts the protocol and Bo=
b turns down the opportunity to earn 10,000 WJT (opportunity cost).<br>
5.=C2=A0 Bob provides signatures for the WJT funding tx,<br>
=C2=A0 =C2=A0 * If Bob does not perform this, it aborts the protocol and Bo=
b turns down the opportunity to earn 10,000 WJT (opportunity cost).<br>
6.=C2=A0 Alice signs WJT funding tx and broacasts and confirms.<br>
=C2=A0 =C2=A0 * If Alice does not perform this, Bob invalidates the transac=
tion by spending any of his inputs.<br>
=C2=A0 =C2=A0 =C2=A0 * Alice has an option here, but a very short option: u=
p until Bob grows tired of waiting.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob can make this timeout arbitrarily small, wi=
thout requiring input from Alice.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 What value would there be in a 1-second option,=
even gotten for free, when Alice has spent fees on the BTC-side transactio=
n in the first place?<br>
7.=C2=A0 Alice completes the claim transaction and broadcasts.<br>
=C2=A0 =C2=A0 * If Alice does not perform this, Bob simply waits out the ti=
melock and recovers his funds plus premium.<br>
8.=C2=A0 Bob spends the BTC HTLC via the hashlock path.<br>
=C2=A0 =C2=A0 * If Bob does not perform this, Bob has given money for free =
to Alice.<br>
<br>
Thus I do not believe this is needed for blockchain-layer atomic swaps.<br>
<br>
For Lightning-layer atomic swaps, the solution requires that two hashes be =
used on the WJT side, and is largely the above protocol in very broad strok=
es.<br>
Unfortunately, using two hashes instead of one leaks to intermediate hops t=
hat the payment involved a cross-currency swap, thus undesirable.<br>
<br>
<br>
<br>
><br>
> In a word, Bob is responsible for preparing the WJT transaction, while=
Alice is responsible for preparing the BTC transaction and broadcasting bo=
th transactions.<br>
><br>
> Here, if Bob stalls, nothing will happen, because Bob cannot spend the=
10,000 WJT premium without Alice=E2=80=99s signature.<br>
> If Alice stalls, you are saying that Bob can spend the input of 1,000,=
000 WJT so he does not lose any money.<br>
><br>
> I have 3 questions on this scheme.<br>
><br>
> First, I=E2=80=99m not sure how do you define =E2=80=9CAlice stalls=E2=
=80=9D. In this case, Alice can stall by 1) withhold the WJT tx, or 2) broa=
dcast BTC/WJT funding txs but withhold the preimage.<br>
> If 2), this protocol is okay. But what about 1) i.e. Alice withholds t=
he WJT tx? Here, Bob cannot do anything except for closing the payment chan=
nel and quit.<br>
<br>
Yes.<br>
<br>
><br>
> Second, I=E2=80=99m not sure whether Bob can spend his money in this p=
ayment channel while the payment channel is still valid.<br>
> In Bitcoin, Bob needs to close the payment channel and get back his mo=
ney first, then he can spend the money.<br>
<br>
Depends on how the payment channel is implemented.<br>
If you do something like send transactions spending the internal state outp=
uts, then ratifying this later by performing a transaction cut-through to d=
erive the next state update, then it is no different from blockchain layer.=
<br>
Of course, if you postulate the non-cooperation of Alice in this, there is =
indeed a need to close unilaterally.<br>
But this is the same as any non-cooperation in any channel system: that is =
the entire point why you have unilateral closes.<br>
<br>
><br>
> Third, let=E2=80=99s optimistically assume Bob can close this payment =
channel without Alice=E2=80=99s consent.<br>
<br>
Every payment channel system worth consideration today has a unilateral clo=
se.<br>
There is no need for optimism.<br>
<br>
> Now he decides to close this channel if Alice does not broadcast the W=
JT tx all the time.<br>
> Alice does not need to pay for the premium if she withholds the WJT tx=
. If Alice decides not to proceed this swap, Bob should close this channel =
and get back 1,000,000 WJT. However, Bob cannot get the 10,000 WJT premium.=
<br>
<br>
And this time frame can be made arbitarily small by Bob by simple threat of=
unilateral close, thus not making it an option for Alice.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000cd6dd6058fe81133--
|