The #Bitcoin #Lightning Spec Part 7/8: P2P Node and Channel Discovery
This part of the spec describes the messages used to relay information about channels and nodes in the network; it replaces both a previous IRC variant used by c-lightning (following in the footsteps of early bitcoin) and a previous suggestion to only have one type of message and no updates which was seen as too simple.
It’s important to note that nodes don’t have to advertise their channels: this is only for nodes which want to route for non-neighbors.
There are three kinds of messages:
- Channel announcements; these give the unspent 2-of-2 output for the channel, with signatures to prove the two nodes signing the announcement own the transaction.
- Node announcements: signed by the node pubkey, contains IP address to connect to a node (if at all), and extra information like a cute alias and color preference for explorers. To quote the spec:
… the rgb-color and alias allow intelligence services to give their nodes cool monikers like IRATEMONK and WISTFULTOLL and use the color black.
- Channel updates: signed by one of the nodes, these give the minimum HTLC accepted, fee percentage and base, and expiry delta required (in blocks).
Creating (and not spending) a bitcoin 2-of-2 output is required for announcing a channel, and announcing a channel is required for announcing a node, so this provides us with a simple DoS protection mechanism. As all updates are batched in 60 second groups, so that provides some limited protection against channel update spamming, too. On a new connection, they simply dump the entire table; Laolu has proposed a much more efficient scheme in future but this is sufficient for the moment.
There’s another DoS issue: these messages can be up to 64k in length, and nodes need to remember them for relaying. The protocol allows extra bytes for future extension, but that means we could be spammed with 128k per channel instead of ~600 bytes as we’d expect. Thus as a compromise the spec explicitly allows nodes to choose not to relay larger-than-minimal node and channel messages; best would be to do it statistically depending on how oversize it is, to allow small expansions to propagate without interruption.
A minor change for more node address flexibility (eg. both IPv4 and IPv6 addresses) will probably be merged soon; it’ll save some space for Tor, I2P etc. if they don’t want an IP address.
