Gossip Observer: New project to monitor the Lightning P2P network

[jonhbit]

@rustyrussell

How about:

1. Send a sketch every 60 seconds. You may reduce the set before sending.
2. If you receive a sketch you can decode, simply reply with any messages the sender is missing.
3. If you can’t decode:
   1. If they are on a different blockheight, ignore.
   2. If you can send a larger set, do so next time.
   3. If you have other peers, wait until you get more failures.
   4. If they have much less gossip than you, start streaming gossip.
   5. Otherwise, something is wrong, query them for everything (or if you don’t have a channel with them, ignore?).

I don’t really think a query protocol is needed.

Another argument against point 2 / not having some message like GETDATA for requesting message contents, is that you may end up receiving the same message multiple times from multiple peers. I still agree that querying for sketches is not needed; I’m referring to how the full message is sent.

For example, if 2 of my 5 peers have a message that I’m missing, and I send both peers a sketch built from a set missing that message, they would both end up sending me the missing message, and we’ve wasted some bandwidth. If I have to request the message data, I can choose the peer to request from, and request exactly once.

Turns out this was proposed a while ago [WIP] BOLT 7: Inventory-based gossip by sstone · Pull Request #584 · lightning/bolts · GitHub I’m not sure why it got dropped / deprioritized back then in 2020.

To be fair, I think the bandwidth overhead of the ‘push’ version where you send missing messages to your peer should decrease as the reconciliation interval decreases. Which we may want to do for other reasons like keeping the expected set difference small.