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
|
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 D26AFCCC
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 13:15:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D4A468A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 12 Aug 2019 13:15:11 +0000 (UTC)
Date: Mon, 12 Aug 2019 13:15:04 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1565615709;
bh=CMfYwMRG2M5s5qCBdp7xHdRfnNSSzsG79xjGYAed22M=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=lD20sCc056fwh5KWJgbp9k+6K1ixf91SB3inwcVGVMf+amy118YVDF7mu1dDwnYK2
gwTfQ0JXASmcf52EU8Qeyx9b2/iX4gX7hfNDiCN69r7CKKLLG0GDuz3NI+ppL6IoSO
fiGepjfEVVXkXH0eSJDtLYJgKhggG9MiM2BFqF5U=
To: Runchao Han <runchao.han@monash.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <phmro7hOHAALKuYqkqe0bS6DAwkES_62RoExz6VQ-F8ap89igX6IOV1kT07LL57dBlv-y4ujIbTx35z2JXrhIP8xEslVTWlILSqCH0ioAqs=@protonmail.com>
In-Reply-To: <419535C8-DE1D-425B-A38C-4196607E43D3@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>
<OLQmXBBI4kc9mkjbpr92bKp3UFhmg7ZtTn-m_VNinXNDT4CYz9Jf45gpSfxmkzXQLJfchMk7AaqEjbEor-ZJ02xrd_0yb2MOekXfRyovj6U=@protonmail.com>
<419535C8-DE1D-425B-A38C-4196607E43D3@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 13:15:12 -0000
Good morning Runchao,
> Thanks for your explanation. It=E2=80=99s comprehensive.
>
> I think our disagreement is on the step 6.
> In step 6,
>
> - Alice can publish or withhold the WJT tx
> - Bob can wait or unilaterally close the WJT payment channel
>
> I see the following things:
>
> First, both Alice and Bob can do something on the WJT blockchain at this =
stage. What will happen if they publish txs simultaneously?
> For example, Alice publishes WJT tx while Bob publishes the tx closing th=
e channel.
I am uncertain what you refer to by the "WJT payment channel".
What I am proposing here is there is a single funding transaction that will=
output to a modified HTLC where hashlock is Alice+Bob while Timelock is Bo=
b, spending inputs from both Alice (10,000 WJT) and Bob (1,000,000 WJT).
So let me rephrase the nearest question as I understand it:
* What happens when Alice broadcasts the funding tx at the same time as Bob=
double-spends his 1,000,000 WJT input?
As both transactions spend the same input (the 1,000,000 WJT from Bob) then=
what happens depends on the miners.
The miners decide which transaction is valid and gets confirmed onchain.
That is the reason why we need large timeouts in the HTLC constructions: we=
need to give enough time, not only to react to transactions being publishe=
d, but also to have transactions become deeply confirmed.
Otherwise we could have made the timelocks so small as to be practically wo=
rthless as an option.
>
> Second, will the concurrent txs introduce some attacks? =C2=A0I guess con=
current-while-conflicting txs lead to highly unpredictable behaviours.
> For example, Alice or Bob uses high tx fee to bribe miners to accept her/=
his tx, in order to gain some advantage on the concurrent txs?
> Also, the =E2=80=9Cwhale transaction=E2=80=9D works here. Will this intro=
duce some double-spending variants?
Yes, that is why Alice and Bob need to wait for deep confirmations of the t=
ransactions involved.
Once deeply confirmed, they now know which way the protocol went and can sa=
fely perform the next step (or abort the protocol).
>
> Third, assume Bob doesn=E2=80=99t wait any more and closes the channel. I=
n this case, Bob cannot get the premium.
> This is not consistent with the original American Call Option, in which B=
ob should still get the premium.
It does not matter, because Bob doing so *prevents* the option.
Think of it this way:
Suppose we were to meet face-to-face, in order for you to sell me an option=
s contract.
Now, suppose I agree to buy the options contract.
But, while filling up the paperwork, you change your mind.
Until the paperwork is properly filled up, the option does not exist.
Thus, until the paperwork is properly filled,, the option is not exerciseab=
le (and I should not pay anything to you since you did not push through wit=
h completing the option).
This is similar in effect.
>
> To conclude, I find this protocol highly depends on the implementation of=
the payment channel as well as the expertise of participants (Alice and Bo=
b) c.f. relatively low usability.
> We may need a suitable payment channel implementation here. What=E2=80=
=99s your opinion on the payment channel suitable for this scenario?
Any payment channel has the problem of non-cooperation by the other side.
I already mentioned this before.
Again, this is always an issue regardless of the existence or non-existence=
of an `OP_LOOKUP_OUTPUT`: you have to execute onchain activity anyway in o=
rder to enforce anything offchain in case of non-cooperation, and adding in=
the possibility of various attacks makes it more likely that non-cooperati=
on occurs.
It is the main reason why I think it is difficult to make Lightning support=
multiple currencies on the same network.
Usability can always be improved by proper software design; you do not worr=
y about what voltage levels need to be transmitted over the wires in order =
to transmit your email to me, yet you probably consider your email client q=
uite usable.
Regards,
ZmnSCPxj
|
