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
|
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 30DA18DC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 08:06:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40B312C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 08:06:02 +0000 (UTC)
Date: Mon, 12 Aug 2019 08:05:53 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1565597159;
bh=F8C1l39rZkf56mrqj+B/UHLiPd7K4ecy8WL6aNGmpJQ=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=oanAx4fwRRs7x8Hkx2y8fALbNDc2Kd/UYgnEFNRhc4iXM7uEE7upuj6qPqkywu+tm
Ju5CCmzcmofRxjqfM0t5Jc8cr7czYI94dPvJA8Kn4XRMQUgd5Dxvi9Rj9Hoqb+ZhwI
Qg49SSFElbk7R4vNCkESM12O+3sfG/G1Nj7uN51U=
To: Runchao Han <runchao.han@monash.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <OLQmXBBI4kc9mkjbpr92bKp3UFhmg7ZtTn-m_VNinXNDT4CYz9Jf45gpSfxmkzXQLJfchMk7AaqEjbEor-ZJ02xrd_0yb2MOekXfRyovj6U=@protonmail.com>
In-Reply-To: <212E8AD5-0EED-468E-8AFC-134611514CBC@monash.edu>
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>
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: 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 08:06:05 -0000
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 Me=
ssage =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> w=
rote:
> 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 B=
ob, 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 an=
d 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 va=
lid 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 no=
t completed.
1. Alice broadcasts and confirms a BTC transaction paying an HTLC, hashloc=
k Bob, Timelock Alice.
* Alice is initiating the protocol via this step, thus non-completion o=
f 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 transactio=
n.
* If Alice does not perform this, it aborts the protocol and Alice lock=
ed her own money for no reason.
* If Bob does not perform this, it aborts the protocol and Bob turns do=
wn the opportunity to earn 10,000 WJT (opportunity cost).
4. Alice and Bob exchange signatures for the WJT-side claim transaction wh=
ich spends the funding transaction via the hashlock side and gives 1,000,00=
0 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 lock=
ed her own money for no reason.
* If Bob does not perform this, it aborts the protocol and Bob turns do=
wn 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 do=
wn 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 sp=
ending any of his inputs.
* Alice has an option here, but a very short option: up until Bob gro=
ws tired of waiting.
Bob can make this timeout arbitrarily small, without requiring inpu=
t from Alice.
What value would there be in a 1-second option, even gotten for fre=
e, 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 be =
used on the WJT side, and is largely the above protocol in very broad strok=
es.
Unfortunately, using two hashes instead of one leaks to intermediate hops t=
hat the payment involved a cross-currency swap, thus undesirable.
>
> In a word, Bob is responsible for preparing the WJT transaction, while Al=
ice 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) b=
roadcast 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.
Yes.
>
> Second, I=E2=80=99m not sure whether Bob can spend his money in this paym=
ent 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 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.
Of course, if you postulate the non-cooperation of Alice in this, there is =
indeed a need to close unilaterally.
But this is the same as any non-cooperation in any channel system: that is =
the entire point why you have unilateral closes.
>
> Third, let=E2=80=99s optimistically assume Bob can close this payment cha=
nnel without Alice=E2=80=99s consent.
Every payment channel system worth consideration today has a unilateral clo=
se.
There is no need for optimism.
> 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. I=
f 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.
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
|
