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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id D6982C0733
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Jul 2020 10:17:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id C5FF2898B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Jul 2020 10:17:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id JaEY7dtM+zeU
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Jul 2020 10:17:05 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by hemlock.osuosl.org (Postfix) with ESMTPS id EB02B898AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Jul 2020 10:17:04 +0000 (UTC)
Date: Fri, 03 Jul 2020 10:16:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1593771422;
bh=2qwsLli10co8rtlCeNqblTvEt1w0Bs6y0v4NtONQTr8=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=xdtlBKf0fLWuo/7CGOwFdQGMacm3DdrMmh18GTL9Dd0Z2zB1iQP5mdUB6qBFO+bQW
7A3MMPCrLt8cheWga9BImGKrVr7HXqDITzT8oW+mVL5AlnEPwM9sX3XBnM2lZ91Mw7
2yiHLxLvstG0E+yFb+ids3VRV7bpLvrH3nBkoK88=
To: Tejaswi Nadahalli <nadahalli@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <-R0O_3IqpmbxNSONd1A2peCnpEIRs73ZELJgsBf06ygq4BGMo3Hg9h4OlXiGuIUyaITWixSY7LlgVyJ2MkAFQb7Y6I1gC8AXiAeS7eMlSso=@protonmail.com>
In-Reply-To: <CAAifmATpg21K=yvi8OaPgr2esdtciu_uNLmNbA8983iht7Ru_Q@mail.gmail.com>
References: <CABT1wW=X35HRVGuP-BHUhDrkBEw27+-iDkNnHWjRU-1mRkn0JQ@mail.gmail.com>
<CABT1wW=KWtoo6zHs8=yUQ7vAYcFSdAzdpDJ9yfw6sJrLd6dN5A@mail.gmail.com>
<20200628121517.f3l2mjcy7x4566v3@ganymede>
<WYQRrIi65yvBWc9qsqCxHWadrMFtYPh2wI-IzVS15FBTFmpIXqHwj5yrj3Igpr-9sKygWsH4DkI_maWcULKKQb51Xp_xZBvKuPF_HmCvqb4=@protonmail.com>
<CAAifmATmQSUUsEbouVYTNNMu-BT8vQiGvh3jwLNK4CUB11s7mg@mail.gmail.com>
<Fh70O0CqbkbLaOUEqRzIG3MOOZi_tYz69xRDPlIlF5tgTIPdYF9LyeoJjypo-agN9-WkuoXJD896R6CQygTozeHA_CFULp3k7007PioaDrs=@protonmail.com>
<CAAifmARxvG+_Wo3zba6MCd=jxwesb2JhWAwRErq6QPVTe1AQEA@mail.gmail.com>
<YhzMZ419vB1BY4Opd3lwfSSJ6_4AIQUDDtZPPhyB2HgskDZv0DKCQlEOAFklskLp1mj5AZrI43VPXOslX25MO-3Fijl9pBWrWYlYiaERr70=@protonmail.com>
<CAAifmATpg21K=yvi8OaPgr2esdtciu_uNLmNbA8983iht7Ru_Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Matan Yehieli <matany@campus.technion.ac.il>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Itay Tsabary <sitay@campus.technion.ac.il>
Subject: Re: [bitcoin-dev] MAD-HTLC
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 03 Jul 2020 10:17:07 -0000
Good morning Tejaswi,
> > But if an attack happens during a fee spike, then even though we retain=
our current default `to_self_delay` of 144, we still have the ability to g=
radually and automatically move to higher fee regions until our transaction=
confirms, and we have a good excuse for it to present to users: "a fee spi=
ke was happening at the time, so you had to pay some extra miner fees".
>
> Agree on the UX. There is a tradeoff between the timelocked value of the =
channel balance to Alice during benign vs malicious abandonment by Bob. In =
your opinion, increasing the fees beyond 1% (and thereby cutting into Alice=
's share itself) is a slightly better tradeoff than increasing to_self_dela=
y.=C2=A0
Currently, we say `to_self_delay` is a parameter of how long you can be off=
line, and is imposed on your counterparty (so its effect on you is to allow=
the counterparty to safely be offline for that long).
This explanation seems palatable to users; they understand that it is the c=
ounterparty which is asking this of them, and that they ask a similar numbe=
r of their counterparty, which is also their own protection.
On the other hand, we do not really expect to get beyond 1% unless we are u=
nder attack, *or* the fee spikes are really, really bad.
So this seems a practical tradeoff for us over in Lightning-land.
> > And since you and your paper openly discusses it anyway, I would like t=
o reveal that the MAD-HTLC argument does not apply to *just* HTLCs.
>
> We know. Maybe we should have made it clear in the paper that when we use=
the Poon-Dryja channel construction, we use the idea that the knowledge of=
the preimage of a hash is equivalent to knowing the private key of the rev=
ocation public key. In fact, this is how the Poon-Dryja construction is exp=
lained in McCorry's Ph.D thesis, and IMHO is easier to understand than the =
original description in the Poon-Dryja paper (or Bolt #3, for that matter).=
=C2=A0
Yes, I realized it a little after reading MAD-HTLC that it applied to all t=
he other known channel mechanisms as well, not just HTLCs, and decided to i=
nvestigate this topic further, and have been circumspect regarding this.
> You could further argue that the hashlock=C2=A0is an incidental artefact,=
and our paper mostly refers to timelocked transactions. And the rest of yo=
ur email describes applications of timelocked (and obviously presigned) tra=
nsactions, which are all vulnerable to the same bribing attack. Additionall=
y, the Wattehnofer in our paper is the same Wattenhofer from the Duplex Cha=
nnel paper.
Yes, I agree that the hashlock is an incidental artefact.
What MAD-HTLC questions is our assumption that a valid transaction with an =
earlier locktime supersedes a valid transaction spending the same txout wit=
h a later locktime.
Whether it involves presigned transactions or hashlocks are incidental arte=
facts.
So for example, a SCRIPT `OP_IF <A> OP_ELSE <1 day> OP_CHECKSEQUENCEVERIFY =
OP_DROP <B> OP_ENDIF OP_CHECKSIG` would also be vulnerable to the MAD-HTLC =
argument.
(Indeed, BOLT spec uses something very much like that script, now that I lo=
ok at it again; in our case the `<A>` is a combination of keys from both pa=
rties, that cannot be signed with unless one party knows both sub-keys.)
>
> > My current analysis suggests that in practice, the MAD-HTLC argument do=
es not apply at all (else I would not be revealing that all channel mechani=
sms are broken **if** the MAD-HTLC argument *does* apply), since the myopic=
strategy seems to be pretty much inevitably dominant at stable states.
>
> We agree.=C2=A0
> =C2=A0
>
> > But it would still be best to investigate further until we are fully co=
nvinced that the MAD-HTLC argument ("'earlier supersedes later' might be fa=
lsified by bribery") does not apply.
>
> I think this is the analysis our paper does, and perhaps it's our mistake=
that we do not set the context better. We only mention (and propose fixes =
for) Poon-Dryja channel construction, and Tier Nolan's Atomic Swap construc=
tion.=C2=A0
>
> We could have addressed Spilman's one-way channels or Decker-Wattenhofer =
duplex channels, but that would have been pointless as they were never goin=
g to make it into production after Poon-Dryja and subsequently, Eltoo were =
proposed.
I suggested that, until `SIGHASH_ANYPREVOUT` gets enabled, the Decker-Watte=
nhofer construction (removing the duplex Spilman-like channels at the end a=
nd leaving just the decrementing-`nSequence` constructions) could be used f=
or Ruben Somsen StateChains, so you might not want to dismiss that so readi=
ly.
The decrementing-`nSequence` mechanisms have the advantage that it does not=
require a punishment/revocation branch, similar to Decker-Russell-Osuntoku=
n "eltoo", and thus would work just as well to implement statechains, at le=
ast until all the debates around `SIGHASH_ANYPREVOUT` settle and it gets de=
ployed.
Similarly, the proposed CoinPool as well could be implemented using Decker-=
Wattenhofer, assuming it gets any details or support behind it sufficientl=
y to push it before `SIGHASH_ANYPREVOUT` gets deployed.
> But not addressing Eltoo in the paper is an omission that I am a bit upse=
t about. We additionally do not address more sophisticated atomic swaps fro=
m Somsen or Fournier. Nor do we address Kanzure's vault proposal. In fact, =
one rule of thumb might be that wherever watchtowers are required, a timelo=
cked bribe might be possible.=C2=A0
I think a better heuristic is that, if the logic of the construction assume=
s "transaction with earlier locktime supersedes transaction with later lock=
time", then it is timelocked-bribery-vulnerable.
Regards,
ZmnSCPxj
|
