# Gossip Observer: New project to monitor the Lightning P2P network **URL:** \ **Category:** Protocol Design\ **Tags:** lightning, taproot\ **Created:** [November 14, 2025, 8:48pm UTC](https://delvingbitcoin.org/t/gossip-observer-new-project-to-monitor-the-lightning-p2p-network/2105 "2025-11-14T20:48:38Z")\ **Posts on this page:** 1\ **Showing post:** 21
**Author:** ![jpjuni0r](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/jpjuni0r/32/1719_2.png) [@jpjuni0r](https://delvingbitcoin.org/u/jpjuni0r)\ **Post date:** [December 18, 2025, 8:07am UTC](https://delvingbitcoin.org/t/gossip-observer-new-project-to-monitor-the-lightning-p2p-network/2105/21 "2025-12-18T08:07:24Z")
You raise some quite interesting points! > [@jonhbit](#): > > Even with how well-connected I expect the P2P network to be now, given the default number of connections implementations make (5+), there are reports of nodes missing messages related to entire subgraphs / neighborhoods of the payment network. Since you are talking about neighborhoods, do you think that the gossip graph is partitioned? I think that three random gossip syncers should be enough that there is only a single partition, though that assumes that every node works reliably. > [@jonhbit](#): > > > [@jpjuni0r](#): > > > > Bandwidth usage certainly is certainly one point worth looking at. Others could be: > > > > - **Reducing message delays** : Based on measurements from @jonhbit, about 95% of nodes receive a message after 600 sec.Note that this measurement includes only those nodes that _do_ forward a given gossip message to the observer node. Furthermore, the observer node had 900 concurrent connections at peak time. However, there are around 1,250 nodes in the channel graph with known IP socket addresses. This raises the question why 28% of IP nodes were not reachable. > > True - that value of 900 initial connections was just an arbitrary starting point tbh. I’m planning to have something more thought-out for the upcoming version of the observer 🙂 > > Re: reachability - one theory I heard recently is that many of the nodes that have both Tor and clearnet address in their node\_announcment have misconfigured routers / firewalls, such that they broadcast an IPv4 address in their node\_announcement but can’t accept inbound IPv4 connections. I know Bitcoin Core has spent a lot of effort on this, with the (deprecated) UPnP support, and now NAT-PMP / PCP support. I suspect that implementations may broadcast IPv4 IPs without verifying that they can accept such connections. Concerning the topic of “node liveness”, I can provide some additional numbers from a similar measurement, compared to yours, that I did a few months ago. While the results generally align with yours, my gossip observer also connected to Tor nodes and we let it run for longer (10 days continuously). Overall, the gossip observer had an average of 4,195 peers out of 16,626 peers in the channel graph (Aug. 16, 2025). Also, we find that 4,859 nodes created at least one new gossip message during that time. Looking at a larger timeframe of 55 days, we find that 7,579 were reachable at least once, and we made connection attempts to 13,165 nodes. The latter number is smaller than the number of nodes in the channel graph, since 5,607 nodes are private nodes in the channel graph with no socket addresses advertised. Still, even when ignoring the private nodes, I find that it is not ideal that there are nodes in the network that are not reachable, and it raises the question, whether they are able to process payments. That number of 4,859 nodes that recently created a new gossip message also was unexpected for me. For a typical channel, I find that they typically create a new channel update at least every 24 hours. Another related point to your goal minimizing bandwidth: I found that there is a small minority of nodes that are very “chatty”. Those frequently create redundant channel updates or node announcements, that differ only in their timestamp and signature fields. In once case, there is a node creating a new node announcement every 30 sec. > [@jonhbit](#): > > > [@jpjuni0r](#): > > > > My goal is to understand the practical side, how much optimizations in the latter two points are warranted and what would be considered “good enough” for the network. > > Based on offline feedback from implementers (and my own opinion), reliability in converging to a full network view / being in sync, is much more important than the convergence delay. Followed by resource usage and implementation complexity. > > I should be able to better observe the difference in network views over time once I start collecting data from multiple ‘observers’ at different positions in the P2P network. What exactly do you mean by “different positions” in the P2P network? Is that just a different selection of gossip syncers? To give you another idea of experimentation: By using a special `gossip_timestamp_filter` message, you could request the entire channel graph from each node and then check, which information is missing. > [@jonhbit](#): > > > [@jpjuni0r](#): > > > > - **Increasing reliability of sending messages** : Based on the results from the [gossip\_observer repo](https://github.com/jharveyb/gossip_observer/blob/54320cca572afbf78873749e0f5d2f3c997d379a/README.md#how-many-peers-sent-us-the-same-message), there are only very few messages that \>500 nodes forward to the observer node. In the graph, there are various peaks in the ranges of 0, 100, 700 and 900 nodes. Importantly, most messages are only received by \<500 of nodes whereas in a perfect network, each of the 900 nodes receives every message. > > Some of that may be that my connection count was changing (decreasing) over time, to a final count of ~700 peers IIRC. So that peak at 700 likely still represents reliable propagation. > > For the peak of 100, I think that may be related to different propagation behavior for certain message types; I’ll try to follow up on that. Looking forward to your investigation! I can also share that analysis based on my dataset (below), where there are only two peaks: One around 0 and the other one around the number of average peers that the node had. Though I did not include all messages received in the results, but made two methodological adjustments: In the first plot labeled “Messages”, I already excluded messages that were historical. That is, when before starting the measurement, I first let the monitor synchronize its channel graph with the other nodes. When starting the actual measurement, I only include those messages that the node has not seen before. Since there are [some nodes](https://github.com/lightningdevkit/rust-lightning/blob/2efb0098793ce2632006c5573f9f0dae7fb6a22a/lightning/src/routing/gossip.rs#L780-L839), sending their entire channel graph for new connection, it skews the results. Another influence I looked at (plotted as “with deduplication”) is the staggered broadcast mechanism, where a node shall only forward a gossip message with the greatest known timestamp field. As this is one mechanism, where messages could be dropped, I changed the methodology to consider a node “receiving” a message when forwarding message _m_, or any of its successors m’ (where timestamp field of _m’_ is greater than that of _m_) to the gossip observer node. That further changes the results to what would be expected from the network: That every one of the ~4,500 connected nodes received each message. Though I cannot explain why there are so many messages in the 0–500 node range on the left that, apparently, starve. ![diagram](https://delvingbitcoin.org/uploads/default/original/2X/3/3e9e0c006cabb4871edd0cf44656a5f1c5a04fec.png) --- _[View the full topic](https://delvingbitcoin.org/t/gossip-observer-new-project-to-monitor-the-lightning-p2p-network/2105)._