[Lightning-dev] daemon/p2p protocol

Rusty Russell rusty at rustcorp.com.au
Mon Oct 19 18:44:19 UTC 2015


Anthony Towns <aj at erisian.com.au> writes:
> Hey *,
>
> A few thoughts on the daemon/p2p protocol in slightly longer form than
> is feasible on IRC...
>
> # protobufs or capnp or flatbuffers or ...
>
> Currently lightning relies on protobuf's with union support, which
> requires a newer version of protobuf-c than is in Debian or Ubuntu.
> I've filed this as http://bugs.debian.org/801950 -- seems to be an
> easy fix.
>
> 11:43  * rusty looks at capnproto, is tempted to see what that would
>          look like compared to protobufs.
>
> capnp's canonical implementation is in C++ rather than C; the C version
> is serialisaion-only, which seems like it loses the fancy time-travel
> RPC feature? C and Python versions of capnp don't seem to be packaged
> for Debian. Not a show-stopper afaics, but I'm not seeing the benefit?

I like the capnproto design, and protobufsq v3 has already been introduced by
Google to deprecate protobufs v2.

However, bitcoin already uses protobufs for the payment protocol, and as
your research reveals, it's more widely supported.

> 11:44 <rusty> But it still doesn't have fixed-length fields, which is a
>               PITA.
>
> FWIW, I think that "fixed-length fields" is just a schema/IDL thing? ie
> the serialised format should still have a byte or two to specify format
> and length (because it's no big deal and slightly safer/saner when
> deserialising), but if it's not the correct value from the schema/.proto
> file, you get an error when you try to de/serialise.

You want the deserialization to do as much sanity checking as possible,
*particularly* when it comes to lengths of things.  Working around this
feature is YA footgun.

> With protobufs, I think you could do this with custom field options:
>
> https://developers.google.com/protocol-buffers/docs/proto?hl=en#customoptions 

I use multiple values, which is even uglier but supported
out-of-the-box.

> # lightning public keys...
>
> I think there are (at least) three uses for public key crypto in lightning:
>
>   1) routing keys -- used for constructing the onion. the routing public
>      key is essentially the node's identity as far as lightning is
>      concerned and must be well known and associated with channels
>      and fees for routing to be possible. *However* a single lightning
>      instance might play host to multiple routing keys.  (This would be
>      less efficient for the network, but might be a win for privacy or
>      might be dictated by deployment reasons...)

Mats calls this "nodepubkey" and I've just been calling it "nodeid".

>   2) anchor keys -- used for spending the anchor transaction for a
>      channel and thus signing commitment transactions; only needs to be
>      known by the counterparty you're constructing a channel with; can
>      be different for every channel.

Yeah, Mats suggested nodes publish the proof from anchor key -> routing
key.

>   3) p2p keys -- used for establishing a shared secret when talking to a
>      node, to avoid your p2p communications being available to someone
>      else (either a passive observer or a MITM). could be different for
>      every connection, or could just have one the lightning instance.

Indeed, current crypto handshake starts with this key exchange, then
proves ownership of the routing key.

> # p2p protocol...
>
> If Alice tries to connect to Bob, I think the current protocol (as of
> git commit gc7eaa4f, from daemon/cryptopkt.c) is:
>
>   Alice: "Call me <RichGirl57914>."
>   Bob: "Call me <MoneyBags70623>."
>
> Then, encrypted to key based on ECDH(RichGirl57914, MoneyBag70623):
>
>   Alice: "RichGirl57914 is actually Alice, signed <Alice>"
>   Bob: "MoneyBags70623 is actually Bob, signed <Bob>"
>
> This is secure against passive monitoring; and after the signatures are
> verified, it's also secure against MITM attacks.
>
> It seems like it has a couple of downsides though:
>
>  - if you're accepting incoming p2p connections, you'll reveal your node
>    id to anyone who asks

Yes, unless you wait for them to go first.  Of course, only one side can
do this...

>  - if the node you're connecting to is MITM'ed, you'll reveal your node
>    id before realising you're MITM'ed
>
>  - you can't run multiple node ids on a single connection
>
>  - Bob has to do crypto operations for every connection, leading to
>    potential DoS attacks
>
> I think treating the relationship between a network address (IPv4/IPv6
> addr and port, tor service) and the lightning network address as sensitive
> is valuable. Revealing a network address helps reveal physical identity,
> makes denial-of-service attacks straightforward, and gives a point of
> entry for targetted hacking to steal your money.

It would be possible to move to a different address once authenticated.
But someone needs to run public nodes.

Cheers,
Rusty.


More information about the Lightning-dev mailing list