[Lightning-dev] Preventing MITM - Providing new nodes with real pubkeys

Rusty Russell rusty at rustcorp.com.au
Tue Oct 20 23:15:26 UTC 2015


Peter Todd <pete at petertodd.org> writes:
> On Tue, Oct 20, 2015 at 04:55:04PM +1030, Rusty Russell wrote:
>> Mats Jerratsch <matsjj at gmail.com> writes:
>> > Think about an attacker who is able to MITM your internet connection,
>> > like the hotspot you connect to at a Cafe (or your ISP if hijacked).
>> > They can build locally a gigantic network, all pointing to the same
>> > node. You can't tell, and they don't have to necessarily just block
>> > your payments. (see above)
>> >
>> > I am mainly concerned over those. Especially since there is not really
>> > anything we can do about dishonest nodes joining our network, but it's
>> > encouraging to see your math. Since everything security-wise so far
>> > stands only with knowing pubkeys of nodes actually connected to the
>> > network, this should be the first thing to tackle. (that is, making it
>> > expensive to attack it this way)
>> 
>> Well, bitcoin protects from this using checkpoints, which are
>> centralized.  Because AFAICT there's no really good way of doing it.
>
> Actually, I'd point out that checkpoints aren't as centralized as you'd
> think! Checkpoints are set sufficiently far back in the past that if
> they come into play for any reason other than initial bootstrapping, an
> active attacker exists that has sufficient hashing power to destroy
> Bitcoin anyway. Thus, checkpoints do *not* need consensus between
> different implementations; my Bitcoin implementation can set a different
> checkpoint than yours and both will work fine, except in the case of
> massive attacks that Bitcoin can't survive anyway.

Bitcoin implementations could remove the confusion by simply specifying
how much total work there is expected to be, but that still allows
nuisance attacks with alternate chains.

My point was more that "it's good enough for bitcoin" so don't feel too
bad if we end up with clients hardcoding details about the lightning
network they expect to connect to (at the very least, its size).

Thanks,
Rusty.


More information about the Lightning-dev mailing list