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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1DE37C77
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Aug 2019 14:29:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
[185.70.40.130])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0942167F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Aug 2019 14:29:36 +0000 (UTC)
Date: Fri, 09 Aug 2019 14:29:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1565360973;
bh=2yTqBDY/cLGy2vM7QtI0YyPRexLTmCdeoEUcb8yLWTc=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=hrwC/3kHQQFL5SeBEi00gc0l55RVDhGjACTFBIqX/uVflp3xHCTRmR8yemRx+6Xfl
tMy+zmMST4SloIJ0tPHcYNovEwOs1FxSIH90IBkGcLuBavpaWPqjgxDKMgB5gAwFKO
2WGVCsOopCaNF/bFRV98dpXiWDx/3FinbYiA0wZ0=
To: Haoyu LIN <chris.haoyul@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <qBFyALsLsiKkSXsssc3T7dvwrXtzBXmAAmTFWAt04AkrFwbWnoCdGIjoyqMZGnJa5Y4CX5mi0-1uWtuzPT5Swr3txw6NthtkOUdzCOlyfXo=@protonmail.com>
In-Reply-To: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com>
References: <CAEtgg6GOdceubg+b=-MvH66CKGBy-67mbQR01JpG3L1YJ1jaVw@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: "jiangshan.yu@monash.edu" <jiangshan.yu@monash.edu>,
"runchao.han@monash.edu" <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: Fri, 09 Aug 2019 14:29:40 -0000
Good morning Haoyu LIN et al.,
> We have investigated this problem in very detail. We analysed how profita=
ble the arbitrage can be given the default timelock setting (24/48 hrs). Ou=
r 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/2=
019/896, and the related code https://github.com/HAOYUatHZ/fair-atomic-swap=
if interested.
>
> Several studies have proposed for solving this problem e.g., http://diyhp=
l.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ and https://c=
oblox.tech/docs/financial_crypto19.pdf. Their basic idea is that, the trans=
action for the premium needs to be locked with the same secret hash but wit=
h 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: Bo=
b can get the premium without paying anything, by never participating in.
>
> To solve this, the transaction verifier needs to know the status of an de=
pendent transaction. Unfortunately, Bitcoin does not support the stateful t=
ransaction functionalities. Therefore, we propose the new opcode: OP_LOOKUP=
_OUTPUT. It takes the id of an output, and produces the address of the outp=
ut=E2=80=99s owner. With OP_LOOKUP_OUTPUT, the Bitcoin script can decide wh=
ether Alice or Bob should take the premium by `<output> OP_LOOKUP_OUTPUT <p=
ubkeyhash> 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 spen=
ding 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` migh=
t 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 ente=
rs the mempool.
Thus it cannot get information about the block it is in.
Instead, the SCRIPT interpreter can have as input only the transaction th=
at is attempting to spend the SCRIPT.
In any case:
> However, this introduces a new problem: Bob can get the premium without p=
aying 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 premi=
um 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 a=
s it still requires the preimage, and at this point, only Alice knows the p=
reimage.
9. Alice and Bob sign the funding transaction and broadcast it.
10. Alice completes the claim transaction by adding the preimage and broad=
casts it.
11. Bob sees the preimage on the WJT blockchain and claims the BTC using t=
he 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 cl=
aim the premium only.
This is basically this proposal: https://lists.linuxfoundation.org/pipermai=
l/lightning-dev/2019-January/001798.html
In addition, if you really want the premium to be denominated in BTC, I hav=
e a more complicated ritual: https://lists.linuxfoundation.org/pipermail/li=
ghtning-dev/2019-January/001795.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
|
