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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 108CE9C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 18:54:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 68BC01BB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Aug 2015 18:54:07 +0000 (UTC)
Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6])
by mail.bluematt.me (Postfix) with ESMTPSA id 3D30E57411;
Fri, 14 Aug 2015 18:54:03 +0000 (UTC)
To: Mark Friedenbach <mark@friedenbach.org>,
Joseph Poon <joseph@lightning.network>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
<20150813234213.GH2123@lightning.network>
<CAOG=w-vJ3DQdXoVfdyXPQXWCvS=ByW-CgqY50OEZYfQbxR5bMg@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55CE3947.8060802@mattcorallo.com>
Date: Fri, 14 Aug 2015 18:53:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAOG=w-vJ3DQdXoVfdyXPQXWCvS=ByW-CgqY50OEZYfQbxR5bMg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 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 18:54:08 -0000
On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote:
> On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto: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.
My concern is how the hell do you automate this? Having a threat of
"well, everyone could update their software to a new version which will
destroy all coins right now" is kinda useless, and trying to come up
with a reasonable set of metrics as to how much and when you move from
just paying the fee to destroying coins is really hard, especially if
you assume the attacker is a miner with, say, enough hashrate (maybe
rented) to get one or three blocks in the next day (the timeout period).
> 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.
Now users are coordinating quickly in an attack scenario?
> 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?
Yea, implementation is really tricky here. I do not at all think we
should be thinking about implementing this any time soon, and should
assume Lightning will have to stand reasonably on its own without it
first, and only if it gains a lot of traction will there be enough
motivation for making such a change at the Bitcoin protocol level for
Lightning.
> A simpler solution to me seems to be outsourcing the response to an
> attack to a third party
Doesnt that defeat the purpose of Lightning?
> 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.
I'm not even sure if sufficient coordination is a sufficient solution.
If you assume a hub just shut down, and everyone is trying to flush to
the chain, with a backlog of a few days worth of transactions (with
timeouts of a day or so), and users are even paying huge fees (99% of
what they'd get back), if the former-hub is a miner, it can claim that
last 1% of many of the transactions that take longer than a day to confirm.
|
