channel_update/channel_announce/node_announcement are sent out of order

[TheBlueMatt]

I don't see a bug report for this, but it generates a ton of debug log output in rust-lightning and c-lightning, so I presume I just couldn't find it.

BOLT #7 is pretty clear: first you have to announce a channel via channel_announce, and only then can you send a node_announcement (as otherwise the routing DB could be easily DoSed). Further, only after channel_announces can you send channel_updates, for obvious reasons, and you shouldn't announce channel_updates which are older than the newest version that you announced.

Sadly, lnd violates all of these, resulting in channels/nodes not being properly included in routing DBs.

[Roasbeef]

Here's our initial dump code: https://github.com/lightningnetwork/lnd/blob/master/discovery/gossiper.go#L287

As you can see we follow all the guidelines. Perhaps you're attempting to implement a stricter set of guidelines? We haven't had any issues with eclair or c-lightning on this front. If we had been no lnd channels would even propagate on mainnet.

[TheBlueMatt]

Heh, I can't read that, but both c-lightning and rust-lightning log what appears to be the same bug - mostly a ton of "Couldn't find channel for update" (implying a channel_update was received without ever having seen a channel_announcement, or at least there would have been an error printed if the channel_announcement had been rejected, which I don't see any of) and "Bad gossip order from subdaemon: WIRE_CHANNEL_UPDATE before announcement" from c-lightning lines when connected to an lnd peer, at least during initial gossip. Maybe messages are getting unordered somewhere else or updates are coming in paralell from somewhere else?

[Roasbeef]

Investigated this a bit, and we always send them in order. The only time we may send a channel update before the channel announcement is if you open a channel to us, as you already "know" of the channel, so we're sending it in case this is a private channel and also to ensure it actually propagates.

If you're running the lnd nodes that's generating these errors, then running it with --debuglevel=PEER=debug will show the order that they're being sent out in. We always send out these messages serially, however, if you're trying to validate them in parallel, then you'll need to use a dependency DAG to ensure you know of the channel before trying to parse the update, etc.