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
|
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 58B3886
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 00:47:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com
[209.85.213.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D3D1141
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 00:47:37 +0000 (UTC)
Received: by igbjg10 with SMTP id jg10so2517311igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Aug 2015 17:47:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=hogEvUGBcTedK7MW8kgh4bsh/hs4TMXBddPWj8cH3eA=;
b=Hm9fwTEn9j7f7owa351xjf+30Dqp0UfbfyLGJbEew047/Qvs/4VxiYKr1Bghocw35a
xMh9gZ546Hu20OWhAuOx4KPA8me3Z3uy5E+QW4CECk5V1a+baNpyVn/3VBMYOwLlPQ5O
6xeS07D6PEbNIwNSZoDe6Ee+qqiuZ28MdyZ+Or2tZCE1pt8XbbtjrNqloFrWgS/U0nWI
0ESg6EchMhCvXVscs3vg6FJijrGiWLfOg+qHLuKfANLh3kmSyPu5TqKWn1aoSLnrGNOm
Cb5kryDV467kD3jdNOXhAUShI3v4+Q9SzMyu0QAjDiN8OOYR2CVebhBAeXSJP1V2WSjb
VP7g==
X-Gm-Message-State: ALoCoQnVmMAdLpetMq0figyq2Nkmg9vJcVdrkItAcNqYknpJo+fNmzZeqSUpwDPakayBs2Bc6aIU
X-Received: by 10.50.43.227 with SMTP id z3mr173151igl.22.1439513256876; Thu,
13 Aug 2015 17:47:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.138.14 with HTTP; Thu, 13 Aug 2015 17:47:17 -0700 (PDT)
X-Originating-IP: [172.56.17.178]
In-Reply-To: <20150813234213.GH2123@lightning.network>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
<20150813234213.GH2123@lightning.network>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 13 Aug 2015 17:47:17 -0700
Message-ID: <CAOG=w-vJ3DQdXoVfdyXPQXWCvS=ByW-CgqY50OEZYfQbxR5bMg@mail.gmail.com>
To: Joseph Poon <joseph@lightning.network>
Content-Type: multipart/alternative; boundary=089e0111c01653acc7051d3accb0
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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 Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for
relative locktime
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 14 Aug 2015 00:47:38 -0000
--089e0111c01653acc7051d3accb0
Content-Type: text/plain; charset=UTF-8
On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I haven't tested the details of this, but is there another bit available
> for use in the future for the relative blockheight?
>
> I strongly believe that Lightning needs mitigations for a systemic
> supervillan attack which attemps to flood the network with transactions,
> which can hypothetically be mitigated with something like a timestop
> bit (as originally suggested by gmaxwell).
>
This proposal includes no such provision.
Since we talked about it, I spent considerable time thinking about the
supposed risk and proposed mitigations. I'm frankly not convinced that it
is a risk of high enough credibility to worry about, or if it is that a
protocol-level complication is worth doing.
The scenario as I understand it is a hub turns evil and tries to cheat
every single one of its users out of their bonds. Normally a lightning user
is protected form such behavior because they have time to broadcast their
own transactions spending part or all of the balance as fees. Therefore
because of the threat of mutually assured destruction, the optimal outcome
is to be an honest participant.
But, the argument goes, the hub has many channels with many different
people closing at the same time. So if the hub tries to cheat all of them
at once by DoS'ing the network, it can do so and spend more in fees than
any one participant stands to lose. My issue with this is that users don't
act alone -- users can be assured that other users will react, and all of
them together have enough coins to burn to make the attack unprofitable.
The hub-cheats-many-users case really is the same as the
hub-cheats-one-user case if the users act out their role in unison, which
they don't have to coordinate to do.
Other than that, even if you are still concerned about that scenario, I'm
not sure timestop is the appropriate solution. A timestop is a
protocol-level complication that is not trivial to implement, indeed I'm
not even sure there is a way to implement it at all -- how do you
differentiate in consensus code a DoS attack from regular old blocks
filling up? And if you could, why add further complication to the consensus
protocol?
A simpler solution to me seems to be outsourcing the response to an attack
to a third party, or otherwise engineering ways for users to
respond-by-default even if their wallet is offline, or otherwise assuring
sufficient coordination in the event of a bad hub.
--089e0111c01653acc7051d3accb0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-d=
ev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></spa=
n> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">I haven't tested the details of this, but is the=
re another bit available<br>
for use in the future for the relative blockheight?<br>
<br>
I strongly believe that Lightning needs mitigations for a systemic<br>
supervillan attack which attemps to flood the network with transactions,<br=
>
which can hypothetically be mitigated with something like a timestop<br>
bit (as originally suggested by gmaxwell).<br></blockquote><div><br></div><=
div>This proposal includes no such provision.<br><br></div><div>Since we ta=
lked about it, I spent considerable time thinking about the supposed risk a=
nd proposed mitigations. I'm frankly not convinced that it is a risk of=
high enough credibility to worry about, or if it is that a protocol-level =
complication is worth doing.<br><br></div><div>The scenario as I understand=
it is a hub turns evil and tries to cheat every single one of its users ou=
t of their bonds. Normally a lightning user is protected form such behavior=
because they have time to broadcast their own transactions spending part o=
r all of the balance as fees. Therefore because of the threat of mutually a=
ssured destruction, the optimal outcome is to be an honest participant.<br>=
<br></div><div>But, the argument goes, the hub has many channels with many =
different people closing at the same time. So if the hub tries to cheat all=
of them at once by DoS'ing the network, it can do so and spend more in=
fees than any one participant stands to lose. My issue with this is that u=
sers don't act alone -- users can be assured that other users will reac=
t, and all of them together have enough coins to burn to make the attack un=
profitable. The hub-cheats-many-users case really is the same as the hub-ch=
eats-one-user case if the users act out their role in unison, which they do=
n't have to coordinate to do.<br><br></div><div>Other than that, even i=
f you are still concerned about that=C2=A0 scenario, I'm not sure times=
top is the appropriate solution. A timestop is a protocol-level complicatio=
n that is not trivial to implement, indeed I'm not even sure there is a=
way to implement it at all -- how do you differentiate in consensus code a=
DoS attack from regular old blocks filling up? And if you could, why add f=
urther complication to the consensus protocol?<br><br></div><div>A simpler =
solution to me seems to be outsourcing the response to an attack to a third=
party, or otherwise engineering ways for users to respond-by-default even =
if their wallet is offline, or otherwise assuring sufficient coordination i=
n the event of a bad hub.<br></div></div></div></div>
--089e0111c01653acc7051d3accb0--
|
