Who Patches the Lightning Network? Evidence from Release Lines in Gossip, 2023-2026

arXiv:2610.30350 · cs.CR, cs.NI · Submitted 2026-10-21 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: We're looking at the paper: "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, 2023-2026".

Elias: Here's the gist of the paper. The gist Every implementation of Bitcoin’s Lightning payment network disclosed security vulnerabilities in 2026, and every advisory told operators to upgrade Every implementation of Bitcoin’s Lightning payment network disclosed security vulnerabilities in 2026, and every advisory told operators to upgrade.

Nadia: Release-line inference from gossip The paper shows that the release line can be read from gossip after all.

Elias: The release line of a public node can be read from its gossip A release line is the finest unit gossip separates; patch releases are invisible.

Nadia: Where a node states its version, the inference is close to exact: on CLN nodes whose alias names the version, the most likely line is right for 132 of 136 node–line pairs.

Title and authors: Nadia: So we're talking about this paper, "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, two thousand twenty-three-two thousand twenty-six <ref:2610.30350#pg1,Evidence from Release Lines in Gossip, 2023-2026>." Basically, the whole point is that even though Bitcoin doesn't send a version string in its gossip messages, you can figure out exactly which release line a node is on by comparing what it announces to known releases from different implementations like LND or CLN.

Elias: Yeah, so it's about using these feature bits announced by nodes to map them onto the actual software release lines of those four different network implementations. It’s trying to show that gossip isn't just random chatter; it carries enough information to tell us who is updating when.

Priya: But what does this actually tell us about the real-world security situation? Are we seeing a clear pattern in who is staying on old, vulnerable code?

Nadia: It suggests that the network patching behavior isn't driven by the official disclosure advisories; it’s more about when operators or platforms push updates. The paper shows that most upgrades happen within months of a release, and the biggest upgrades are often tied directly to platform releases, like when Umbrel shipped a new LND version.

Elias: That's interesting because it moves the focus away from just reacting to alerts. It suggests we can predict upgrade waves by looking at platform schedules rather than waiting for security notices. The paper notes that since June two thousand twenty-five seventeen percent of LND upgrades happened within forty-eight hours of a platform release, which covers about four point four percent of the total time <ref:2610.30350#pg1>.

Priya: So it's not just about the speed of patching; it’s about the timing relative to other network activity. If we can predict when a major platform drops an update, we can anticipate when a chunk of nodes will be moving to that new line and potentially out of danger.

Nadia: Exactly. And then there's what happens after a disclosure, like when Lightning Labs sends out an advisory in two thousand twenty-six <ref:2610.30350#pg1>. The paper found that for most LND nodes, the exposure doesn't increase much even after the announcement. Two months later, seventy-one percent of those exposed nodes were still running an affected release.

Title and authors: Elias: That’s a strong finding because it suggests that the notification itself isn't a strong enough incentive for operators to patch immediately when they are already close to current. It implies that the actual patching decision is often driven by other factors, like platform releases or simply being near the end of their cycle.

Priya: I wonder if this means security advisories become less effective as a standalone trigger for immediate remediation? If you're already on a line where things are about to change anyway, maybe the advisory doesn't move you enough.

Nadia: That’s one interpretation. But look at the CLN results; they showed something different when operators asked who could not upgrade to restart offline. The nodes that went offline were mostly already patched, only eleven percent of those behind were affected, compared to twenty-three point four percent on the newest line.

Elias: That comparison is telling because it shows that when you force a move, the nodes are much more likely to actually follow through than just passively waiting for an advisory. It links the patch timing directly to operator response behavior.

Priya: So, what we're seeing is this distinction between passive exposure and active migration based on external triggers or direct action requests from operators. That data structure, tracking release lines against platform schedules and disclosure timings, really helps quantify that gap in response times.

Nadia: It does. And the paper points out a limitation right there—it can't measure patch releases directly because gossip doesn't have version strings; it only sees the line changes. So we can't see the fix itself, only where the line boundary is and who moves across it after months of waiting.

Elias: Right, so we are measuring the movement on release schedules, not instantaneous fixes within a release cycle. That means we have to look at how far nodes are from a known line when they get caught in an advisory window, which is what the paper does with those bounds analysis.

Priya: And for me, the method seems robust because it uses feature bits and checks consistency across different implementations—LND, Core Lightning, Eclair, and LDK—which gives us a solid anchor point to infer that release line. It’s not just looking at one network in isolation.

Nadia: Exactly. So for anyone listening who only cares about the security risk on their current setup, this means understanding that your node's software version is subtly visible in its gossip behavior, and you can use that to gauge how vulnerable you are compared to the network average moving on release schedules.

Title and authors: Elias: It shifts the research from just proving a protocol works to mapping the operational reality of how users interact with that protocol over time. That’s a significant shift in focus for us as cryptographers, moving toward deployment dynamics.

Priya: And looking ahead, this paper sets up a framework for better risk assessment by quantifying exactly how long nodes remain exposed after an advisory goes out, which is something we need when we're designing defenses against these kinds of software vulnerabilities.

Nadia: So to wrap up the paper "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, two thousand twenty-three-two thousand twenty-six" it’s about showing that the network patching schedule is driven by platform releases and operator behavior more than security advisories alone <ref:2610.30350#pg1,Evidence from Release Lines in Gossip, 2023-2026>. It uses gossip to infer release lines across different implementations and shows that most operators patch on their own schedule within months of a release.

Elias: And the core improvement is using this line inference to predict upgrade waves based on external schedules, like those from Umbrel, which gives us a way to proactively plan capacity when major platform updates are coming.

Priya: From my side, the limitation is clear: since gossip doesn't see patch releases inside a line, we can't measure how fast an operator fixes something mid-cycle; we only get bounds on that exposure period.

Nadia: That’s the trade-off. But overall, it gives us a concrete way to look at the operational side of Bitcoin security—it shows who is patching based on release schedules rather than just reacting to the news cycle.

Elias: So we're looking at how different protocols handle version announcements and how that translates into real-world security posture over several years of data. It’s a good look at deployment reality for payment channels.

Priya: It gives us better data on exposure tracking, which is crucial when we try to model the risk profile of systems that rely on these decentralized networks.

Nadia: That's it for this paper, "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, two thousand twenty-three-two thousand twenty-six <ref:2610.30350#pg1,Evidence from Release Lines in Gossip, 2023-2026>." We’ve got a lot more work ahead in modeling how AI agents interact with these systems.

The paper's summary: Nadia: So we're talking about this paper "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, two thousand twenty-three-two thousand twenty-six." It’s basically saying that even without version numbers in the gossip messages, you can figure out which software release line a node is on by looking at what it announces.

Elias: Yeah, it uses these feature bits to map nodes onto actual software release lines from different implementations like LND or CLN. It’s trying to show that gossip isn't just random chatter; it carries enough information to tell us who is updating when.

Priya: But what does this actually show us about the real world? Are we seeing a clear pattern in who is staying on old, vulnerable code?

Nadia: It suggests that patching behavior isn't driven by official security advisories as much as it is by when operators or platforms push updates. The paper shows that most upgrades happen within months of a release, and the biggest upgrades are tied directly to platform releases.

Elias: That’s interesting because it moves the focus away from just reacting to alerts. It suggests we can predict upgrade waves by looking at platform schedules rather than waiting for security notices. The paper notes that since June two thousand twenty-five seventeen percent of LND upgrades happened within forty-eight hours of a platform release, which covers about four point four percent of the total time.

Nadia: Exactly. And then there's what happens after a disclosure, like when Lightning Labs sends out an advisory in two thousand twenty-six. The paper found that for most LND nodes, the exposure doesn't increase much even after the announcement. Two months later, seventy-one percent of those exposed nodes were still running an affected release.

The paper's summary: Elias: That’s a strong finding because it suggests that the notification itself isn't a strong enough incentive for operators to patch immediately when they are already close to current. It implies that the actual patching decision is often driven by other factors, like platform releases or simply being near the end of their cycle.

Priya: So what we're seeing is this distinction between passive exposure and active migration based on external triggers or direct action requests from operators. That data structure, tracking release lines against platform schedules and disclosure timings, really helps quantify that gap in response times.

Nadia: And the paper points out a limitation right there—it can't measure patch releases directly because gossip doesn't have version strings; it only sees the line changes. So we can't see the fix itself, only where the line boundary is and who moves across it after months of waiting.

The paper's summary: Nadia: Exactly. So for anyone listening who only cares about the security risk on their current setup, this means understanding that your node's software version is subtly visible in its gossip behavior, and you can use that to gauge how vulnerable you are compared to the network average moving on release schedules.

Elias: It shifts the research from just proving a protocol works to mapping the operational reality of how users interact with that protocol over time. That’s a significant shift in focus for us as cryptographers, moving toward deployment dynamics.

Priya: And looking ahead, this paper sets up a framework for better risk assessment by quantifying exactly how long nodes remain exposed after an advisory goes out, which is something we need when we try to model the risk profile of systems that rely on these decentralized networks.

Nadia: So to wrap up this paper, "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, two thousand twenty-three-two thousand twenty-six" it’s about showing that the network patching schedule is driven by platform releases and operator behavior more than security advisories alone. It uses gossip to infer release lines across different implementations and shows that most operators patch on their own schedule within months of a release.

Priya: It gives us better data on exposure tracking, which is crucial when we try to model the risk profile of systems that rely on these decentralized networks.

The paper's improvements: Nadia: So we're talking about how they suggest improving their work on that Lightning Network paper. They’re not just showing what happened; they’re proposing ways to make this line inference even better for figuring out who patches the network.

Elias: Right, it seems like they want to move beyond just looking at node announcements and start building models that predict upgrade waves more accurately based on those schedules we saw earlier.

Priya: What does that mean for us in terms of privacy or measurement? Are these improvements actually helping us get a clearer picture of the network behavior?

Nadia: It means they want to use upgrade dynamics modeling to forecast how quickly different classes of nodes upgrade based on their capacity and channel count. They're talking about estimates like "larger nodes upgrade sooner by a factor of one point one one per tenfold capacity."

Elias: That sounds like they’re trying to build discrete-time models to predict adoption curves over months. It moves the research from just observing past data to actually forecasting future network migration events.

Priya: So it shifts the focus toward actionable prediction rather than just retrospective analysis of what happened in two thousand twenty-six. That seems like a step toward being able to anticipate network stress points before they become actual problems.

Nadia: Yeah, and then there's the platform release scheduling part. They suggest using this data to identify those three largest LND upgrade waves by dating node re-announcements against platform releases directly.

Elias: That’s a direct way to connect the dots between a specific platform update and a measurable movement in the network state. It gives us proactive capacity planning when we know a major platform is shipping something new.

Priya: That sounds useful for risk assessment because it lets you anticipate where the congestion will be, which is exactly what we need when we're trying to model system strain.

Nadia: And finally, they suggest using disclosure response modeling to see how much those security advisories actually move operators. They want to measure the rate of leaving affected lines after a fix is announced.

Elias: That’s looking at the effectiveness of those advisories in driving operator action, which we touched on before. It wants to quantify whether an advisory is a strong enough signal for someone who's already near the end of their patch cycle.

Priya: So these improvements seem to focus heavily on using timing and capacity metrics to create predictive tools for network stability and risk modeling.

Nadia: Yeah, it’s about making the inference practical—turning gossip patterns into something that helps operators plan their defense or upgrade strategy ahead of time.

Elias: It's moving toward a system where the network behavior isn't just described by what happened, but by what we can estimate will happen next. That’s a big step for parameter selection in proofs too.

Conclusion: Tom: So we’re wrapping up this look at "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, two thousand twenty-three to two thousand twenty-six." Basically, they showed that we can infer node software release lines just by looking at their gossip chatter.

Nadia: Yeah, it’s a way to map out who is patching the network based on when they release updates or when operators decide to move. It proves that the patching schedule isn't just random; it follows a pattern tied to deployment cycles and platform releases.

Elias: And they’re proposing models that can actually predict those upgrade waves using capacity and channel count data, which is pretty cool for forecasting network migration events.

Priya: But what does this mean for us in terms of data? Does this inference method give us any real privacy concerns when we’re tracking these node behaviors over time?

Nadia: Well, the authors did address that by focusing on aggregates and only publishing results, but the core idea is using release lines to track exposure, which helps us quantify risk over time.

Elias: Exactly. It changes how we look at security problems because instead of just reacting to a single advisory notification, we can track how long nodes stay exposed on older lines after a fix is announced.

Priya: That sounds like it gives us better tools for modeling the real-world impact of those advisories, which is what I was hoping for with this kind of measurement research.

Nadia: So to summarize "Who Patches the Lightning Network? Evidence from Release Lines in Gossip, two thousand twenty-three to two thousand twenty-six" they used gossip patterns to map node versions and found that operator schedules and platform releases are the main drivers of patching behavior.

Elias: It’s a concrete way to understand deployment dynamics in practice, moving beyond just theoretical proofs about what should happen.

Priya: It gives us better data on exposure tracking, which is crucial when we try to model the risk profile of systems that rely on these decentralized networks.

Nadia: Exactly. Now I think we need to see how this kind of version inference works when you introduce things like AI agents interacting with these systems. That’s what we’ll be looking at next.

Bitcoin Data Labs

cs.CR, cs.NI

Submitted: 2026-10-21

Updated: 2026-10-21

Comments: 13 pages, 7 figures, 5 tables. Code and aggregate data: https://github.com/bitcoindatalabs/ln-upgrade-dynamics

Code: https://github.com/bitcoindatalabs/ln-upgrade-dynamics

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 80/100

The gist: The gist Every implementation of Bitcoin’s Lightning payment network disclosed security vulnerabilities in 2026, and every advisory told operators to upgrade Every implementation of Bitcoin’s

Key concepts

Release Line: A specific sequence of software versions for a particular implementation (like LND or CLN). Gossip allows systems to read these lines by identifying consistent feature bits announced in consecutive releases, even when version numbers are hidden.
Upgrade Dynamics: This models how quickly different types of nodes upgrade based on their capacity and channel count. The study finds that larger nodes upgrade sooner, providing a way to forecast network adoption curves over several months.
Platform Pace: This tracks how large node platforms influence upgrades by releasing new versions simultaneously. The research identifies specific timing correlations between platform releases and major node upgrade waves, allowing for proactive capacity planning.
Disclosure Response: This measures the effectiveness of security advisories by tracking operator behavior after a vulnerability is disclosed. It quantifies how quickly operators move off vulnerable lines following an advisory, showing that some advisories significantly accelerate this action.

Summary

The gist Every implementation of Bitcoin’s Lightning payment network disclosed security vulnerabilities in 2026, and every advisory told operators to upgrade Every implementation of Bitcoin’s Lightning payment network disclosed security vulnerabilities in 2026, and every advisory told operators to upgrade.

Release-line inference from gossip

The paper shows that the release line can be read from gossip after all. The release line of a public node can be read from its gossip A release line is the finest unit gossip separates; patch releases are invisible. Where a node states its version, the inference is close to exact: on CLN nodes whose alias names the version, the most likely line is right for 132 of 136 node–line pairs. LND nodes state no version, so we check three things that must hold if the inference is right, and all three do.

Upgrade dynamics

Most operators upgrade within months; the ones that lag are small or already behind. Half of the LND nodes on an older line upgrade within 88 days of a release; the smallest quarter of nodes takes 135, and a node already more than one line behind has about five times lower odds of moving in any week. These figures set apart a managed fleet of up to 1,781 live LND nodes, whose schedule would otherwise dominate them.

Platforms set the pace

The largest upgrades are node platforms shipping a release to all their users at once. Dating the releases of two platforms to the minute from public records, we find that the three largest LND upgrade waves, 262–385 nodes each, came about a day after the Umbrel app store published a new LND version, and another followed BTCPay Server’s security release. Since June 2025, 17% of LND upgrades came in the 48 hours after a platform release, windows that cover 4.4% of the time but hold 17% of LND upgrades.

Disclosure, response and exposure

Disclosure moved few operators, and mostly those already close to current. For the 30 LND and CLN advisories whose fix boundary gossip can see, we measure how many live nodes and how much capacity stayed exposed; the fixes typically shipped months before disclosure (median 256 days). Only CLN’s July 2026 disclosures raised that rate, by a factor of 3.87 among nodes one line behind. No LND disclosure produced a detectable increase.

Robustness

Table V varies the definitions behind the four case studies. A 7- or 28-day liveness window moves the exposure by about one percentage point. The strict lower bounds for LND sit well below the likely-line exposure, because a newer line with some default features switched off can produce the bits of an older one.

Conclusion

Lightning gossip carries no version string, but the feature bits each release announces identify its release line closely enough to measure who patches the network Operators patch on release schedules: most upgrade within a few months of a release. Platforms patch on theirs: the largest single movements are node platforms shipping a release to all their users at once. Disclosures, which typically come long after the fix, move few nodes A tail of small and neglected nodes stays on vulnerable releases.

The gist The release line can be read from gossip after all; operators on their own schedule, the platforms that package the implementations, or the advisories themselves determine who patches the Lightning Network.

Release lines

We built a table of the node announcement feature bits of every release of the four implementations from their source at each release tag. Consecutive releases with identical defaults form a release line, the finest unit gossip can resolve: LND has 10 lines from 0.8 to 0.21, CLN 13, Eclair 13 and LDK 6. For a node with feature set B, a line l with defaults Dl, optional bits Ol and removable bits Rl is consistent when Dl - Rl ⊆ B ⊆ Dl∪Ol.

Implementation

Release lines are defined per implementation, so the implementation comes first. We use the client inference of our previous paper [12]: implementation-specific feature bits decide most nodes, operators whose implementation is publicly known are attributed directly, and weak signals (LND’s default colour or alias, default CLTV deltas) label the rest with low confidence.

Validation

CLN built in developer mode puts the version into the default alias (e.g. YELLOWWATER-v25.09); the alias follows the binary, so it is correct on every day the node is announced. On CLN nodes whose alias names its version, the most likely line is right for 132 of 136 node–line pairs.

Upgrade waves

Upgrades arrive in bursts (Fig. 5). The three largest were set by Umbrel, not by LND Each followed Umbrel’s release of a new LND version (0.19.1, 0.20.0 and 0.21.1), which came 19–41 days after LND’s own. The timing is Umbrel’s: in each wave, at least 87% of the 262–385 nodes signed their new announcement within 48 hours after Umbrel merged the release (median 16–27 hours after), and at most 1% in the 24 hours before.

Advisory gossip can see

An advisory is visible in gossip when its fix boundary coincides with the start of a release line (LINE), or falls inside a line but leaves whole lines affected or fixed on either side (PARTIAL, which gives bounds). Fixes inside the newest line, such as CLN 26.06.7–26.06.9 and Eclair 0.14.1–0.14.3, are patch releases and invisible.

What became of the exposed nodes

Most LND nodes exposed at disclosure stayed exposed. On the day Lightning Labs disclosed its batch, 14.9% of live LND nodes, holding 6.4% of live LND capacity, were on a line older than 0.19 (Fig. 7). By the cutoff two months later, 71% of them were still live on an affected line; 10% had upgraded and 20% were no longer live.

Advisory response

The nodes one line behind moved steadily (indented row of Table IV). Without platform moves their rate rose 3.87-fold, and each of the four weeks after disclosure had a higher rate than any of the seven before.

Limitations

Release lines, not patches. Gossip cannot separate patch releases, so fixes inside a line, including all of CLN’s 2026 patch releases, cannot be measured; for advisories with a fix inside a line we report bounds. Inference. An operator can switch features on or off so that an older line looks like a newer one or the reverse; the strict range covers every non-developer configuration, and validation on self-identifying CLN nodes bounds the error of the likely line.

Ethics

Release-line inference identifies nodes running vulnerable software, and in 2026 Lightning deployments were exploited (BTCPay Server [41]) and CLN maintainers reported attacks on unpatched nodes [4]. We therefore publish aggregates only: no list, ranking, filter or label of individual nodes by release, platform or exposure, in the paper or in the released data.

Improvements for AI systems

Improved release line inference for Bitcoin payment channel networks allows systems to determine a node's software release line from gossip, even when a version string is not present. This enables systems to accurately measure who patches the Lightning Network by distinguishing between operators patching on their own schedule and platforms pushing updates.
Enhanced upgrade dynamics modeling can predict how quickly different classes of nodes upgrade based on their capacity and channel count. Specifically, systems can estimate that larger nodes upgrade sooner (odds ratio 1.11 per tenfold capacity, 1.14 per tenfold channel count) using discrete-time models to forecast adoption curves in months.
Platform release scheduling can be used to predict large-scale network migration events with high accuracy. Systems can identify the three largest LND upgrade waves by dating node re-announcements against platform releases, allowing for proactive capacity planning when a platform ships a new version.
Disclosure response modeling provides insights into the effectiveness of security advisories in driving operator action. Systems can measure the rate of leaving affected lines after disclosure, noting that CLN’s July disclosures raised the rate of leaving affected lines 3.87-fold among nodes one line behind.
Vulnerability exposure tracking can quantify how long operators remain exposed to known flaws post-disclosure. Systems can determine that two months after Lightning Labs’ August 2026 batch, 71% of the nodes exposed at disclosure still ran an affected release, allowing for accurate risk assessment based on patch deployment timing.

Who Patches the Lightning Network? Evidence from Release Lines in Gossip, 2023-2026

Listen

Transcript

Key concepts

Summary

Improvements for AI systems

Sources

Related papers