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
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
|
Return-Path: <runchao.han@monash.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 387C786D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 03:20:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com
[209.85.210.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 068D4786
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 03:19:59 +0000 (UTC)
Received: by mail-pf1-f196.google.com with SMTP id v12so1227227pfn.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Aug 2019 20:19:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monash.edu; s=google;
h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
:references; bh=y1uJjp8GR1WOwN3q3wLvwflC824KBcfOoByOIU/zwo8=;
b=Lt9rk4rqz7lyyHQTQNru3xAusGq6U+zW7phzNfRbUUY/SgAnABTewkS0GZvWCcLTdO
wGqpbx8qLlvgAPJlbTOD46triPf8fP56g7q9s7LlbJs8Y4v355IR6g8uKMYqepgYZyok
u2ppv1UR0OTx9qbpLrYTxLlIhVoCM8cbNZd7HjW7xQAqezGJ5gVvSwSLZa3NfSz73kCq
DanJGdO3OR3xigsgUKFYhmqxm5FYk8nB4+wNRmVKW0GdIHIeqpLeVpS39U4STLgdLq6g
aXTk0wdbP/co8KIUvRNGVYGl4rqSGRB++yCcex9gMTdj1Af/3zzRY2rXnb+DGbeJwwPw
WGiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:message-id:mime-version:subject:date
:in-reply-to:cc:to:references;
bh=y1uJjp8GR1WOwN3q3wLvwflC824KBcfOoByOIU/zwo8=;
b=oygXpRLQC68mBg9wdxAINYybhPXW6GExhUIxPU/yhxs+iNkVQcRj+j46lDFV4P7gfk
sn0vCYmm+KxfWS9N4e18S5H5a2C77HfzZk/OnqGA4GF1+Dra8EHykYWhk5DaVKbNAb8X
6wF9+3MvZw0msFewXqFTb/0h+8XqNxGHqp6oj0WFXDX3OaAgiM5zUCWhIk6m3j0DJ993
mwrf/GURW1ehrsbEqIRuwT+gWt0kdz/1qXl78YxwKhdjWRVRyPYYhPDlgg/j2sFNugJN
6KuE7kjdBIy+fmgbFUOTolOCIbTOq8MCEDnVT6ra4HVRmKUpwg5waPe3iDw3S9rmWuEY
f6Ng==
X-Gm-Message-State: APjAAAWR4OkOjGgtRCCP9w8SzOolKJtJmpSP5rJwT007a5hYZZ+4wYAh
GLOWv297/MymmTyDaBk5rfaFQw==
X-Google-Smtp-Source: APXvYqyc/9Q4y8wBE+tgVeCBJ+nDEpgzG3CvDuEDvFDvpephME7VuzF1iKGmI4bTdQ3FUDZH03KPoA==
X-Received: by 2002:a63:2744:: with SMTP id n65mr28064201pgn.277.1565579999096;
Sun, 11 Aug 2019 20:19:59 -0700 (PDT)
Received: from ?IPv6:2001:388:608c:2c52:31:ec21:6ba5:f9b1?
([2001:388:608c:2c52:31:ec21:6ba5:f9b1])
by smtp.gmail.com with ESMTPSA id
v14sm111482211pfm.164.2019.08.11.20.19.56
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 11 Aug 2019 20:19:58 -0700 (PDT)
From: Runchao Han <runchao.han@monash.edu>
Message-Id: <212E8AD5-0EED-468E-8AFC-134611514CBC@monash.edu>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_2F88D704-E416-4992-88A9-C3BD700E0DC6"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 12 Aug 2019 13:19:53 +1000
In-Reply-To: <CABnocSBSKsmWeRCOZE6DHwPXc2rucQGkHvjd+wJ+9JAJOT5=QQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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>
X-Mailer: Apple Mail (2.3445.104.11)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, MIME_QP_LONG_LINE,
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: Mon, 12 Aug 2019 03:21:48 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"jiangshan.yu@monash.edu" <jiangshan.yu@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 03:20:02 -0000
--Apple-Mail=_2F88D704-E416-4992-88A9-C3BD700E0DC6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
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 =
below:
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 Bob 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.
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 funding txs but withhold the preimage.
If 2), this protocol is okay. But what about 1) i.e. Alice withholds the =
WJT tx? Here, Bob cannot do anything except for closing the payment =
channel and quit.
Second, I=E2=80=99m not sure whether Bob can spend his money in this =
payment 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.
Third, let=E2=80=99s optimistically assume Bob can close this payment =
channel without Alice=E2=80=99s consent.
Now he decides to close this channel if Alice does not broadcast the WJT =
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 =
premium.
In conclusion, Alice=E2=80=99s optionality is not free when she =
exercises this option, but is free when she aborts this option.
## What will happen if Alice is responsible for broadcasting both =
funding txs
If Alice is responsible for broadcasting both txs, Alice can always =
abort the swap for free, regardless of how the protocol is designed.
Basically, Bob officially participates in the swap by signing the WJT =
tx.
After Bob participating, if Alice hopes to abort the swap, she can just =
withhold the WJT tx.
In the original Atomic Swap, Bob participates in the swap by signing and =
broadcasting the WJT tx, and Alice cannot withhold Bob=E2=80=99s =
participation.
However, if Alice is responsible for broadcasting Bob=E2=80=99s WJT tx, =
Alice can withhold Bob=E2=80=99s participation by withholding the WJT =
tx.
Therefore, I think for Atomic Swap protocol design, Bob should be =
responsible for broadcasting the WJT tx, otherwise the protocol is =
impossible to be fair to Bob.
Again, sorry for the ambiguity introduced in our last email, and we look =
forward to hearing from you.
Thanks,
Runchao
> On 10 Aug 2019, at 11:01 pm, Runchao Han <runchao.han@monash.edu> =
wrote:
>=20
> If I remember it right, Alice first signs the WJT transaction, sends =
it to Bob, then Bob signs it and makes this transaction valid.
>=20
> If so, there are two problems.
> First, Bob gets the valid tx first, and he can choose not to send it =
to Alice.
> Second, even if Bob honestly sends Alice this tx, Alice cannot fully =
control when to broadcast this to, as Bob also has this transaction.
>=20
> If Bob first signs then Alice signs, Alice still has optionality, as =
she can choose whether to publish this tx and preimage.
>=20
> Runchao
>=20
> On Sat, Aug 10, 2019 at 10:50 PM ZmnSCPxj <ZmnSCPxj@protonmail.com =
<mailto:ZmnSCPxj@protonmail.com>> wrote:
> Good morning Runchao,
>=20
>=20
>=20
>=20
> Sent with ProtonMail Secure Email.
>=20
> =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 Saturday, August 10, 2019 1:44 PM, Runchao Han =
<runchao.han@monash.edu <mailto:runchao.han@monash.edu>> wrote:
>=20
> > Hi ZmnSCPxj,
> >
> > Thanks for your reply.
> >
> > I agree with your opinions about OP_LOOKUP_OUTPUT.
> > Indeed, the pruning mechanism renders this opcode unrealistic for =
some nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time =
of verifying this tx.
> >
> > However, I=E2=80=99m concerning of some security issues of your =
mentioned protocol (Alice pays the premium contingently on Bob =
participating).
> > If I understand it right, Alice and Bob should create a payment =
channel, and mutually construct the funding transaction that =E2=80=9CAlic=
e pays Bob 10,000 WJT; Bob hash-timelocked pays Alice 1,000,000WJT=E2=80=9D=
, where the time lock is T+24.
> > Here, Bob is responsible for broadcasting this tx after confirming =
Alice=E2=80=99s funding transaction on BTC blockchain.
>=20
> No, Bob is not.
>=20
> The signature exchange for the WJT-side funding tx is done by:
>=20
> 1. Alice waits for Bob to provide all its signatures for inputs that =
will fund the 1,000,000 WJT payout.
> 2. Alice signs its inputs that will fund the 10,000 WJT premium.
> 3. Alice broadacasts the completely signed funding tx.
>=20
> Alice is the one responsible for broadcasting the funding tx.
>=20
> If Bob stalls, it is not a Bob side option (i.e. Bob cannot stall then =
continue the protocol when the exchange rate moves to its favor) as =
Alice can refuse to sign and broadcast the funding tx once it has =
decided Bob is trolling it, thus Bob cannot force Alice to perform.
>=20
> If Alice stalls, Bob can double-spend one of its inputs at a low =
feerate.
> This either aborts the protocol, or if Alice then broadcasts the =
funding tx at the pre-agreed feerate and it is confirmed, the premium is =
now already paid to Bob.
>=20
> Regards,
> ZmnSCPxj
>=20
> > In this case, Bob can arbitrage by broadcasting this tx after T+24. =
In this way, Bob receives the 10,000WJT, but Alice cannot redeem =
1,000,000WJT anymore.
> > If the premium (10,000WJT) is also hash-timelocked, Alice can keep =
unraveling the preimage, which makes the atomic swap still premium-free.
> >
> > In the original atomic swap, Bob is incentivised to broadcast his =
funding transaction, otherwise he may miss the opportunity to redeem =
Alice=E2=80=99s asset.
> > Also, Alice will lose nothing regardless of how Bob behaves, because =
Alice locks all her money by hashlock.
> > However, Alice cannot lock the premium using hashlock. This gives =
Bob opportunity to arbitrage Alice=E2=80=99s premium.
> >
> > What is implied here is that, where the premium should go strictly =
depends on where Bob=E2=80=99s asset goes.
> > If the Bitcoin=E2=80=99s timelock can be =E2=80=9Crelative=E2=80=9D =
(e.g. the timestamp can be x+24 where x is the timestamp of the block =
with this transaction), I think this protocol works.
> > Unfortunately, the =E2=80=9Cx=E2=80=9D here is also an external =
state according to your definition.
> >
> > In conclusion, I believe your comments on OP_LOOKUP_OUTPUT =
reasonable, but cannot make sure if the premium mechanism can be =
implemented by using HTLCs.
> >
> > Thanks,
> > Runchao
> >
> > > On 10 Aug 2019, at 12:29 am, ZmnSCPxj ZmnSCPxj@protonmail.com =
<mailto:ZmnSCPxj@protonmail.com> wrote:
> > > Good morning Haoyu LIN et al.,
> > >
> > > > We have investigated this problem in very detail. We analysed =
how profitable the arbitrage can be given the default timelock setting =
(24/48 hrs). Our result shows that the profit can be approximately 1% ~ =
2.3%, which is non-negligible compared with 0.3% for stock market. This =
can be attractive as it's totally risk-free. Please refer to our paper =
https://eprint.iacr.org/2019/896 <https://eprint.iacr.org/2019/896>, and =
the related code https://github.com/HAOYUatHZ/fair-atomic-swap =
<https://github.com/HAOYUatHZ/fair-atomic-swap> if interested.
> > > > Several studies have proposed for solving this problem e.g., =
http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ =
<http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/=
> and https://coblox.tech/docs/financial_crypto19.pdf =
<https://coblox.tech/docs/financial_crypto19.pdf>. Their basic idea is =
that, the transaction for the premium needs to be locked with the same =
secret hash but with a flipped payout, i.e. when redeemed with the =
secret, the money goes back to Alice and after timelock, the premium =
goes to Bob as a compensation for Alice not revealing the secret. =
However, this introduces a new problem: Bob can get the premium without =
paying anything, by never participating in.
> > > > To solve this, the transaction verifier needs to know the status =
of an dependent transaction. Unfortunately, Bitcoin does not support the =
stateful transaction functionalities. Therefore, we propose the new =
opcode: OP_LOOKUP_OUTPUT. It takes the id of an output, and produces the =
address of the output=E2=80=99s owner. With OP_LOOKUP_OUTPUT, the =
Bitcoin script can decide whether Alice or Bob should take the premium =
by `<output> OP_LOOKUP_OUTPUT <pubkeyhash> OP_EQUALVERIFY`.
> > >
> > > I believe an unsaid principle of SCRIPT opcode design is this:
> > >
> > > - No SCRIPT opcode can look at anything that is not in the =
transaction spending from the SCRIPT.
> > >
> > > This issue underlies the previous `OP_PUBREF` proposal also.
> > > The reason for this is:
> > >
> > > - We support a pruning mode, where in only the UTXO set is =
retained.
> > > If `OP_LOOKUP_OUTPUT` exists, we cannot prune, as =
`OP_LOOKUP_OUTPUT` might refer to a TXO that has been spent in very =
early historical blocks.
> > >
> > > - The SCRIPT interpreter is run only once, at the time the =
transaction enters the mempool.
> > > Thus it cannot get information about the block it is in.
> > > Instead, the SCRIPT interpreter can have as input only the =
transaction that is attempting to spend the SCRIPT.
> > >
> > >
> > > In any case:
> > >
> > > > However, this introduces a new problem: Bob can get the premium =
without paying anything, by never participating in.
> > >
> > > Premium payment can be made contingent on Bob participating.
> > > Of course, it does mean the premium is paid using the destination =
coin.
> > > It also requires the destination coin to support SegWit.
> > > Let me explain by this:
> > >
> > > 1. Alice and Bob agree on swap parameters:
> > >
> > > - Alice will exchange 1 BTC for 1,000,000 WJT from Bob.
> > > - Alice will pay 10,000 WJT as premium to Bob.
> > > - Alice will lock BTC for 48 hours.
> > > - Bob will lock WJT for 24 hours.
> > > - The protocol will start at particular time T.
> > >
> > > 2. Alice generates a preimage+hash.
> > > 3. Alice pays 1 BTC to a HTLC with hashlock going to Bob and =
timelocked at T+48 going to Alice.
> > > 4. Alice presents above UTXO to Bob.
> > > 5. Alice reveals the WJT UTXOs to be spent to pay for the 10,000 =
WJT premium to Bob.
> > > 6. Alice and Bob generate, but do not sign, a funding transaction =
spending some of Bob coin as well as the premium coin from Alice.
> > > This pays out to 1,010,000 WJT (the value plus the premium) =
HTLC.
> > > The hashlock branch requires not just Alice, but also Bob.
> > > The timelock branch at T+24 just requires Bob.
> > >
> > > 7. Alice and Bob generate the claim transaction.
> > > This spends the funding transaction HTLC output and pays out =
1,000,000 WJT to Alice and 10,000 WJT to Bob.
> > >
> > > 8. Alice and Bob sign the claim transaction.
> > > This does not allow Bob to make the claim transaction valid by =
itself as it still requires the preimage, and at this point, only Alice =
knows the preimage.
> > >
> > > 9. Alice and Bob sign the funding transaction and broadcast it.
> > > 10. Alice completes the claim transaction by adding the preimage =
and broadcasts it.
> > > 11. Bob sees the preimage on the WJT blockchain and claims the =
BTC using the preimage.
> > >
> > > If Bob stalls at step 8, then there is no way to claim the =
premium, as the funding transaction (which is the source of the claim =
transaction that pays the premium) is not valid yet.
> > > After step 9, Bob has been forced to participate and cannot back =
out and claim the premium only.
> > > This is basically this proposal: =
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001=
798.html =
<https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/00=
1798.html>
> > > In addition, if you really want the premium to be denominated in =
BTC, I have a more complicated ritual: =
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001=
795.html =
<https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/00=
1795.html>
> > > The described ritual only sets up the American Call Option, but by =
the time it has been set up, the premium has been paid already and the =
rest of the execution is claiming the American Call Option.
> > > Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.
> > > Regards,
> > > ZmnSCPxj
>=20
>=20
--Apple-Mail=_2F88D704-E416-4992-88A9-C3BD700E0DC6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div =
dir=3D"auto" style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;" class=3D""><div dir=3D"auto" =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;" class=3D"">Good morning ZmnSCPxj,<div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">## Analysis on the protocol from =
Fournier et al.</div><div class=3D""><br class=3D""></div><div =
class=3D"">In this protocol, Bob participates in the swap following the =
steps below:</div><div class=3D""><br class=3D""></div><div class=3D"">1. =
Alice and Bob creates a payment channel on WJT blockchain.</div><div =
class=3D"">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=99=
s input for the 10,000 WJT premium. This transaction should be signed by =
both Alice and Bob in order to be valid.</div><div class=3D"">3. Bob =
signs the WJT transaction and sends the WJT transaction to =
Alice.</div><div class=3D"">4. Alice signs this WJT transaction. At this =
stage, Alice has both the valid BTC transaction and the valid WJT =
transaction.</div><div class=3D"">5. Alice broadcasts both the BTC =
transaction and the WJT transaction.</div><div class=3D""><br =
class=3D""></div><div class=3D"">In a word, Bob is responsible for =
preparing the WJT transaction, while Alice is responsible for preparing =
the BTC transaction and broadcasting both transactions.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Here, if Bob stalls, =
nothing will happen, because Bob cannot spend the 10,000 WJT premium =
without Alice=E2=80=99s signature.</div><div class=3D"">If Alice stalls, =
you are saying that Bob can spend the input of 1,000,000 WJT so he does =
not lose any money.</div><div class=3D""><br class=3D""></div><div =
class=3D"">I have 3 questions on this scheme.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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 funding txs but withhold =
the preimage.</div><div class=3D"">If 2), this protocol is okay. But =
what about 1) i.e. Alice withholds the WJT tx? Here, Bob cannot do =
anything except for closing the payment channel and quit.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Second, I=E2=80=99m not =
sure whether Bob can spend his money in this payment channel while the =
payment channel is still valid.</div><div class=3D"">In Bitcoin, Bob =
needs to close the payment channel and get back his money first, then he =
can spend the money.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Third, let=E2=80=99s optimistically assume Bob can close this =
payment channel without Alice=E2=80=99s consent.</div><div class=3D"">Now =
he decides to close this channel if Alice does not broadcast the WJT tx =
all the time.</div><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D"">In conclusion, Alice=E2=80=99s =
optionality is not free when she exercises this option, but is free when =
she aborts this option.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">## What will happen if Alice is responsible for broadcasting =
both funding txs</div><div class=3D""><br class=3D""></div><div =
class=3D"">If Alice is responsible for broadcasting both txs, Alice can =
always abort the swap for free, regardless of how the protocol is =
designed.</div><div class=3D"">Basically, Bob officially participates in =
the swap by signing the WJT tx.</div><div class=3D"">After Bob =
participating, if Alice hopes to abort the swap, she can just withhold =
the WJT tx.</div><div class=3D""><br class=3D""></div><div class=3D"">In =
the original Atomic Swap, Bob participates in the swap by signing and =
broadcasting the WJT tx, and Alice cannot withhold Bob=E2=80=99s =
participation.</div><div class=3D"">However, if Alice is responsible for =
broadcasting Bob=E2=80=99s WJT tx, Alice can withhold Bob=E2=80=99s =
participation by withholding the WJT tx.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Therefore, I think for Atomic Swap =
protocol design, Bob should be responsible for broadcasting the WJT tx, =
otherwise the protocol is impossible to be fair to Bob.</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">Again, sorry for the =
ambiguity introduced in our last email, and we look forward to hearing =
from you.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Thanks,</div><div class=3D"">Runchao</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On =
10 Aug 2019, at 11:01 pm, Runchao Han <<a =
href=3D"mailto:runchao.han@monash.edu" =
class=3D"">runchao.han@monash.edu</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D""><div =
dir=3D"auto" class=3D"">If I remember it right, Alice first signs the =
WJT transaction, sends it to Bob, then Bob signs it and makes this =
transaction valid.</div></div><div dir=3D"auto" class=3D""><br =
class=3D""></div><div dir=3D"auto" class=3D"">If so, there are two =
problems.</div><div dir=3D"auto" class=3D"">First, Bob gets the valid tx =
first, and he can choose not to send it to Alice.</div><div dir=3D"auto" =
class=3D"">Second, even if Bob honestly sends Alice this tx, Alice =
cannot fully control when to broadcast this to, as Bob also has this =
transaction.</div><div dir=3D"auto" class=3D""><br class=3D""></div><div =
dir=3D"auto" class=3D"">If Bob first signs then Alice signs, Alice still =
has optionality, as she can choose whether to publish this tx and =
preimage.</div><div dir=3D"auto" class=3D""><br class=3D""></div><div =
dir=3D"auto" class=3D"">Runchao</div><div class=3D""><br class=3D""><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug =
10, 2019 at 10:50 PM ZmnSCPxj <<a =
href=3D"mailto:ZmnSCPxj@protonmail.com" =
class=3D"">ZmnSCPxj@protonmail.com</a>> wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Good morning =
Runchao,<br class=3D"">
<br class=3D"">
<br class=3D"">
<br class=3D"">
<br class=3D"">
Sent with ProtonMail Secure Email.<br class=3D"">
<br class=3D"">
=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<br=
class=3D"">
On Saturday, August 10, 2019 1:44 PM, Runchao Han <<a =
href=3D"mailto:runchao.han@monash.edu" target=3D"_blank" =
class=3D"">runchao.han@monash.edu</a>> wrote:<br class=3D"">
<br class=3D"">
> Hi ZmnSCPxj,<br class=3D"">
><br class=3D"">
> Thanks for your reply.<br class=3D"">
><br class=3D"">
> I agree with your opinions about OP_LOOKUP_OUTPUT.<br class=3D"">
> Indeed, the pruning mechanism renders this opcode unrealistic for =
some nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time =
of verifying this tx.<br class=3D"">
><br class=3D"">
> However, I=E2=80=99m concerning of some security issues of your =
mentioned protocol (Alice pays the premium contingently on Bob =
participating).<br class=3D"">
> If I understand it right, Alice and Bob should create a payment =
channel, and mutually construct the funding transaction that =E2=80=9CAlic=
e pays Bob 10,000 WJT; Bob hash-timelocked pays Alice 1,000,000WJT=E2=80=9D=
, where the time lock is T+24.<br class=3D"">
> Here, Bob is responsible for broadcasting this tx after confirming =
Alice=E2=80=99s funding transaction on BTC blockchain.<br class=3D"">
<br class=3D"">
No, Bob is not.<br class=3D"">
<br class=3D"">
The signature exchange for the WJT-side funding tx is done by:<br =
class=3D"">
<br class=3D"">
1. Alice waits for Bob to provide all its signatures for inputs that =
will fund the 1,000,000 WJT payout.<br class=3D"">
2. Alice signs its inputs that will fund the 10,000 WJT premium.<br =
class=3D"">
3. Alice broadacasts the completely signed funding tx.<br class=3D"">
<br class=3D"">
Alice is the one responsible for broadcasting the funding tx.<br =
class=3D"">
<br class=3D"">
If Bob stalls, it is not a Bob side option (i.e. Bob cannot stall then =
continue the protocol when the exchange rate moves to its favor) as =
Alice can refuse to sign and broadcast the funding tx once it has =
decided Bob is trolling it, thus Bob cannot force Alice to perform.<br =
class=3D"">
<br class=3D"">
If Alice stalls, Bob can double-spend one of its inputs at a low =
feerate.<br class=3D"">
This either aborts the protocol, or if Alice then broadcasts the funding =
tx at the pre-agreed feerate and it is confirmed, the premium is now =
already paid to Bob.<br class=3D"">
<br class=3D"">
Regards,<br class=3D"">
ZmnSCPxj<br class=3D"">
<br class=3D"">
> In this case, Bob can arbitrage by broadcasting this tx after T+24. =
In this way, Bob receives the 10,000WJT, but Alice cannot redeem =
1,000,000WJT anymore.<br class=3D"">
> If the premium (10,000WJT) is also hash-timelocked, Alice can keep =
unraveling the preimage, which makes the atomic swap still =
premium-free.<br class=3D"">
><br class=3D"">
> In the original atomic swap, Bob is incentivised to broadcast his =
funding transaction, otherwise he may miss the opportunity to redeem =
Alice=E2=80=99s asset.<br class=3D"">
> Also, Alice will lose nothing regardless of how Bob behaves, =
because Alice locks all her money by hashlock.<br class=3D"">
> However, Alice cannot lock the premium using hashlock. This gives =
Bob opportunity to arbitrage Alice=E2=80=99s premium.<br class=3D"">
><br class=3D"">
> What is implied here is that, where the premium should go strictly =
depends on where Bob=E2=80=99s asset goes.<br class=3D"">
> If the Bitcoin=E2=80=99s timelock can be =E2=80=9Crelative=E2=80=9D =
(e.g. the timestamp can be x+24 where x is the timestamp of the block =
with this transaction), I think this protocol works.<br class=3D"">
> Unfortunately, the =E2=80=9Cx=E2=80=9D here is also an external =
state according to your definition.<br class=3D"">
><br class=3D"">
> In conclusion, I believe your comments on OP_LOOKUP_OUTPUT =
reasonable, but cannot make sure if the premium mechanism can be =
implemented by using HTLCs.<br class=3D"">
><br class=3D"">
> Thanks,<br class=3D"">
> Runchao<br class=3D"">
><br class=3D"">
> > On 10 Aug 2019, at 12:29 am, ZmnSCPxj <a =
href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank" =
class=3D"">ZmnSCPxj@protonmail.com</a> wrote:<br class=3D"">
> > Good morning Haoyu LIN et al.,<br class=3D"">
> ><br class=3D"">
> > > We have investigated this problem in very detail. We =
analysed how profitable the arbitrage can be given the default timelock =
setting (24/48 hrs). Our result shows that the profit can be =
approximately 1% ~ 2.3%, which is non-negligible compared with 0.3% for =
stock market. This can be attractive as it's totally risk-free. Please =
refer to our paper <a href=3D"https://eprint.iacr.org/2019/896" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://eprint.iacr.org/2019/896</a>, and the related code <a =
href=3D"https://github.com/HAOYUatHZ/fair-atomic-swap" rel=3D"noreferrer" =
target=3D"_blank" =
class=3D"">https://github.com/HAOYUatHZ/fair-atomic-swap</a> if =
interested.<br class=3D"">
> > > Several studies have proposed for solving this problem =
e.g., <a =
href=3D"http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic=
-swaps/" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/ato=
mic-swaps/</a> and <a =
href=3D"https://coblox.tech/docs/financial_crypto19.pdf" =
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://coblox.tech/docs/financial_crypto19.pdf</a>. Their =
basic idea is that, the transaction for the premium needs to be locked =
with the same secret hash but with a flipped payout, i.e. when redeemed =
with the secret, the money goes back to Alice and after timelock, the =
premium goes to Bob as a compensation for Alice not revealing the =
secret. However, this introduces a new problem: Bob can get the premium =
without paying anything, by never participating in.<br class=3D"">
> > > To solve this, the transaction verifier needs to know the =
status of an dependent transaction. Unfortunately, Bitcoin does not =
support the stateful transaction functionalities. Therefore, we propose =
the new opcode: OP_LOOKUP_OUTPUT. It takes the id of an output, and =
produces the address of the output=E2=80=99s owner. With =
OP_LOOKUP_OUTPUT, the Bitcoin script can decide whether Alice or Bob =
should take the premium by `<output> OP_LOOKUP_OUTPUT =
<pubkeyhash> OP_EQUALVERIFY`.<br class=3D"">
> ><br class=3D"">
> > I believe an unsaid principle of SCRIPT opcode design is =
this:<br class=3D"">
> ><br class=3D"">
> > - No SCRIPT opcode can look at anything that is =
not in the transaction spending from the SCRIPT.<br class=3D"">
> ><br class=3D"">
> > This issue underlies the previous `OP_PUBREF` proposal =
also.<br class=3D"">
> > The reason for this is:<br class=3D"">
> ><br class=3D"">
> > - We support a pruning mode, where in only the =
UTXO set is retained.<br class=3D"">
> > If `OP_LOOKUP_OUTPUT` exists, we cannot =
prune, as `OP_LOOKUP_OUTPUT` might refer to a TXO that has been spent in =
very early historical blocks.<br class=3D"">
> ><br class=3D"">
> > - The SCRIPT interpreter is run only once, at the =
time the transaction enters the mempool.<br class=3D"">
> > Thus it cannot get information about the =
block it is in.<br class=3D"">
> > Instead, the SCRIPT interpreter can have as =
input only the transaction that is attempting to spend the SCRIPT.<br =
class=3D"">
> ><br class=3D"">
> ><br class=3D"">
> > In any case:<br class=3D"">
> ><br class=3D"">
> > > However, this introduces a new problem: Bob can get the =
premium without paying anything, by never participating in.<br class=3D"">=
> ><br class=3D"">
> > Premium payment can be made contingent on Bob =
participating.<br class=3D"">
> > Of course, it does mean the premium is paid using the =
destination coin.<br class=3D"">
> > It also requires the destination coin to support SegWit.<br =
class=3D"">
> > Let me explain by this:<br class=3D"">
> ><br class=3D"">
> > 1. Alice and Bob agree on swap parameters:<br class=3D"">
> ><br class=3D"">
> > - Alice will exchange 1 BTC for 1,000,000 WJT from =
Bob.<br class=3D"">
> > - Alice will pay 10,000 WJT as premium to Bob.<br =
class=3D"">
> > - Alice will lock BTC for 48 hours.<br class=3D"">
> > - Bob will lock WJT for 24 hours.<br class=3D"">
> > - The protocol will start at particular time T.<br =
class=3D"">
> ><br class=3D"">
> > 2. Alice generates a preimage+hash.<br class=3D"">
> > 3. Alice pays 1 BTC to a HTLC with hashlock going to Bob =
and timelocked at T+48 going to Alice.<br class=3D"">
> > 4. Alice presents above UTXO to Bob.<br class=3D"">
> > 5. Alice reveals the WJT UTXOs to be spent to pay for =
the 10,000 WJT premium to Bob.<br class=3D"">
> > 6. Alice and Bob generate, but do not sign, a funding =
transaction spending some of Bob coin as well as the premium coin from =
Alice.<br class=3D"">
> > This pays out to 1,010,000 WJT (the value =
plus the premium) HTLC.<br class=3D"">
> > The hashlock branch requires not just =
Alice, but also Bob.<br class=3D"">
> > The timelock branch at T+24 just requires =
Bob.<br class=3D"">
> ><br class=3D"">
> > 7. Alice and Bob generate the claim transaction.<br =
class=3D"">
> > This spends the funding transaction HTLC =
output and pays out 1,000,000 WJT to Alice and 10,000 WJT to Bob.<br =
class=3D"">
> ><br class=3D"">
> > 8. Alice and Bob sign the claim transaction.<br =
class=3D"">
> > This does not allow Bob to make the claim =
transaction valid by itself as it still requires the preimage, and at =
this point, only Alice knows the preimage.<br class=3D"">
> ><br class=3D"">
> > 9. Alice and Bob sign the funding transaction and =
broadcast it.<br class=3D"">
> > 10. Alice completes the claim transaction by adding the =
preimage and broadcasts it.<br class=3D"">
> > 11. Bob sees the preimage on the WJT blockchain and =
claims the BTC using the preimage.<br class=3D"">
> ><br class=3D"">
> > If Bob stalls at step 8, then there is no way to claim the =
premium, as the funding transaction (which is the source of the claim =
transaction that pays the premium) is not valid yet.<br class=3D"">
> > After step 9, Bob has been forced to participate and cannot =
back out and claim the premium only.<br class=3D"">
> > This is basically this proposal: <a =
href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Jan=
uary/001798.html" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-=
January/001798.html</a><br class=3D"">
> > In addition, if you really want the premium to be denominated =
in BTC, I have a more complicated ritual: <a =
href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-Jan=
uary/001795.html" rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-=
January/001795.html</a><br class=3D"">
> > The described ritual only sets up the American Call Option, =
but by the time it has been set up, the premium has been paid already =
and the rest of the execution is claiming the American Call Option.<br =
class=3D"">
> > Thus, I believe there is no need to add `OP_LOOKUP_OUTPUT`.<br =
class=3D"">
> > Regards,<br class=3D"">
> > ZmnSCPxj<br class=3D"">
<br class=3D"">
<br class=3D"">
</blockquote></div></div>
</div></blockquote></div><br class=3D""></div></div></div></body></html>=
--Apple-Mail=_2F88D704-E416-4992-88A9-C3BD700E0DC6--
|