Latest Strikes #28 & #29 - July 6th-19th 2026

Welcome to Latest Strikes, your (sometimes bi) weekly report of the latest Lightning-related news. This issue covers 2 weeks’ worth of news, with a Core Lightning DoS vulnerability disclosure, the path queries proposal, and interesting discussions around unilateral exit in Spark.

Core Lightning Vulnerability Disclosure

Chandra Pratap disclosed another vulnerability (actually, 2 vulnerabilities) in Core Lightning. Like the one he revealed in May, those vulnerabilities are DoS vectors, this time through memory exhaustion. These vulnerabilities were respectively fixed in versions 26.04 (April 2026) and https://github.com/ElementsProject/lightning/releases/tag/v26.06rc2 (May 2026).

Both vulnerabilities can be triggered remotely by flooding a node with cryptographically valid channel_update gossip messages.

• The first vulnerability affects a message queue between the connectd and gossipd subprocesses. The former receives messages from peers and passes them down to the latter, which uses them to build a local topology of the network. Messages are queued, and by populating the queue faster than it is emptied (by sending lots of messages) it’s possible to trigger an out-of-memory (OOM) system crash.
• The second vulnerability is internal to the gossipd process, which uses a map to store short channel IDs (SCIDs) it doesn’t know yet, assuming it missed the original channel announcement, and with the intent to check the channel’s existence. By feeding the node a continuous stream of channel_update messages with random SCIDs, it’s possible to remotely trigger a similar OOM system crash.

Like the previous one, these vulnerabilities were also discovered through fuzzing, by iterating over random but cryptographically valid gossip messages.

Chandra Pratap’s Blog: Vulnerability 1 | Vulnerability 2

Path Queries

brh28 “reopened” a proposal for path queries, moving it from the BOLTs repository to the BLIPs’ one. The crux of the idea is to allow nodes to voluntarily respond to queries for optimized paths towards a destination, leveraging the accurate view that each node has on its own channels’ balances. The origin node of a path query can be either the sender of a payment, or a routing node responding to another path query and fetching up-to-date information from peers in order to provide the best reply possible to the original request¹.

In a path query, a node typically asks: “If I wanted to transfer this amount from A to B, which paths do you reckon would work?”. A responder then replies with a set of possible paths, each comprising possibly multiple parts, and across multiple hops. For each hop, the reply indicates the fee to pay. For paths that would span across many hops, the first responder can “forward” the query to the next nodes in the path, gathering more accurate information pertaining to liquidity availability and cost, before providing an answer to the initial query. Since routing nodes only get paid when a payment succeeds, they are incentivized to provide fresh information.

The main goal of this proposal is to improve payment reliability by providing the sending node, which computes the payment route, with accurate information on a path’s feasibility that it would otherwise have to (hopefully educatedly) guess. However, as brh28 notes, reducing this uncertainty necessarily erodes privacy for all nodes engaged in the payments (i.e. sender, receiver and routing nodes). This erosion is of a different nature depending on the affected node, and can be mitigated, although mitigating privacy concerns for one node can potentially result in decreased privacy for other nodes.

Since a path query reveals details about the expected payment, it degrades privacy for both sender and receiver. While the sender doesn’t expose its identity in the path query message (the origin specified there is the node at which the path begins, i.e. the “first responder”) and the composability of the queries (their forwarding from node to node) means no node can ascertain the origin of the request in theory, in practice a range of correlation deanonymization techniques are available (roughly the same used in deanonymizing the payments themselves). The receiving node is also completely revealed to all nodes receiving the path query, unlike in onion-routed payments. Possible mitigations are:

• using blinded paths to obfuscate the actual recipient
• for the sender, performing a first split of the payment into smaller chunks, and sending distinct queries, helping obfuscate the actual payment amount (and destination when used in conjunction with path blinding)
• for the sender, sending the queries as onion messages rather than direct peer messages.

Note that this last solution comes to the detriment of the routing nodes. By answering path queries, they provide data to other nodes that, combined, could be used to assess a node’s balance quite precisely. To put this in perspective, this is already the case currently, since without other means for gathering private information Lightning nodes can use fake payments as probes to determine a channel’s liquidity distribution. Since routing nodes cannot tell apart fake and real payments, they expose information every time they emit a failure message on a route. With path queries, they can at least decide to not answer some queries (by ignoring them or responding with a reject message), or rate-limit queries on a per-peer basis to avoid giving up too much information. This, however, only works if responding nodes can identify the requesting peer, which they cannot do when responding to queries submitted through onion messages.

All in all, I think it’s a fairly interesting proposal. The status quo right now is for nodes to take educated guesses based on public capacity, gossip messages, and potentially probes sent into the network. This tends to increase centralization, since bigger channels typically have a higher probability of having a usable liquidity distribution for a given payment at a given time. Path queries would allow smaller routing nodes to attract more traffic by revealing data, but in a selective and transparent manner rather than through “deceptive” payment probes. Path queries could hence improve payment reliability, settlement time (less retries), and even open the door to just-in-time pricing for routing nodes, unlike what gossip currently enables.

Delving Bitcoin Post | StackerNews Discussion

On Exiting Spark

The last 2 weeks saw interesting discussions around the exact nature of exiting to self-custody in Spark. To me, the discussion seemed to revolve around one main point: most Spark wallets didn’t implement actual unilateral self-custodial exit before going to production, and still don’t.

A unilateral exit is the process by which a Spark user is able to take their funds (or at least most of them, more on that later) off Spark and into a Bitcoin address they control, without any participation from the Spark Entity. Exiting requires 2 things:

• the user’s private key (e.g. a 12/24 words seed)
• the user’s leaf data.

Every time the user receives funds on Spark it’s in the form of a leaf in a tree of unpublished Bitcoin transactions. In order to be able to claim their funds, a user hence needs to know what their leaves are and in which order to claim them. Leaf data is basically “coordinated” by the Spark Entity, which means users’ wallets need to download this data from the Spark Entity servers. In order to ensure unilateral exit is always possible, wallets should hence fetch leaf data from the server after every transaction, guaranteeing they don’t need the server to be online when they later wish to exit.

In practice, the Breez SDK, which a lot of Spark wallets use, didn’t implement the unilateral exit on its main branch; and only one implementation (Stacked, a New Zealand exchange) implemented the unilateral exit (kudos to them!) by (I suppose) leveraging the unilateral exit open PR’s code.

A few days ago, the pull request implementing unilateral exit in the Breez SDK was merged, which hopefully means that unilateral exit will be shipped to most Spark wallets in the coming weeks (insert Padmé/Anakin meme).

Of course, these concerns stack on top of the existing well documented tradeoffs around Spark. It gets worse when users are given something called a “seed” and the impression that they can unilaterally exit even though their wallet doesn’t routinely fetch leaf data. On the plus side, the reaction to last weeks’ increased scrutiny seems to have been the shipping of the missing feature and a better, broader understanding of Spark’s tradeoffs², which is great.

More resources:

• Spark in Blink
• Spark Unilateral Exit in Blink
• Spark in Radar

StackerNews Discussion

That’s it for the last 2 weeks! Thank you so much for reading this far, and until next week!

https://stacker.news/items/1530642