Latest Strikes S03E20 - May 11th-17th 2026

Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week we got Lightning trades in HodlHodl, 40M Lightning Addresses, a Core Lightning release, and more!

Lightning Trades In HodlHodl

HodlHodl unveiled a Lightning integration for their P2P trading platform (now live on mainnet). With its instant settlement, privacy and relatively low fees, Lightning makes a lot of sense for the peer-to-peer trading of reasonable amounts (e.g. anywhere between $1 and $1,000), as evidenced by the success of marketplaces such as Robosats. However, P2P trading platforms usually involve an escrow that holds the funds during the trade, since there is no way to atomically swap between fiat and bitcoin.

Lightning has some kind of native escrow system with hodl invoices, which are already used by Robosats for example. The crux of the idea is that the coordinator of the marketplace charges the seller of bitcoin with a hodl invoice that pays the coordinator. Then, once the seller confirms the buyer has sent their fiat payment, the coordinator will pay the buyer. This is hence an imperfect escrow, since there is a moment where the coordinator has sole control of the funds¹.

In HodlHodl's case, the funds sit in a multisig on Arkade while the trade is ongoing. Basically, the seller swaps funds from Lightning to the Arkade multisig. Then, once the seller confirms they received the payment from the buyer, the multisig releases the funds to the buyer either on-chain or Lightning, through another swap. What makes this economically viable is that the creation of the shared VTXO on Arkade, as well as the swaps to and from it, are virtually free compared to the cost of doing the same on-chain. Compared to the hodl invoice model, going through Arkade:

• distributes the custody of the funds in the multisig across all 4 parties (buyer, seller, HodlHodl and the Arkade operator)²
• gets rid of the hodl invoice, which is quite nice in terms of user experience³.

Virtual Private Node Ships Blinded Paths

Ripsline added blinded paths by default on the Virtual Private Node project, leveraging LND's support. This means that invoices created through the TUI interface will automatically enable the blinded paths option, specifying an introduction point to the paying node and obfuscating the rest of the route.

X Post

Kenyans Get a Lightning Address Without Asking

Tando announced that 40 million Kenyans now have a Lightning Address, without necessarily being aware of it. This works thanks to Tando's solution, which bridges Lightning to the M-Pesa network in Kenya, where users can send and receive mobile money using only a phone number. Tando runs an LNURL Server that receives Lightning payments and forwards them to the requested number as Kenyan Shillings (KES) on the M-Pesa network. For example, paying the Lightning Address [email protected] will result in the user behind phone number (254)717252303 receiving the equivalent amount in KES. Pretty neat.

Core Lightning 26.06 Release Candidate

The first release candidate for v26.06 of Core Lightning was released, bringing a lot of payment improvements, such as:

• the once experimental, but now quite ironed out xpay command now takes precedence over the legacy pay command. Basically, using the pay command now defaults to using xpay under the hood, letting users benefit from the improved pathfinding without having to figure out they should use this weird xpay thing over the pay command ;
• keysend payments can now also enjoy improved pathfinding thanks to the xkeysend command. But when will it replace the keysend command?

Core Lightning Support In Alby Hub

Speaking of Core Lightning, version 1.22.2 of Alby Hub now supports this implementation as the underlying Lightning node, on top of LND and LDK nodes. Will Eclair follow suit?

On top of that, this release also revamped a lot of the administration pages, including the wallet and connections setup pages; and added a new "AI & Agents" section that lets users connect their agents to a wallet through a secure NWC connection, and supercharges the agent with an Alby payment skill.

Predicting Channel Closures With Machine Learning

Amboss published a paper summarizing their attempt at predicting channel closures using various machine learning approaches (multi-layer perceptron, gradient-boosted trees, etc.). The problem these models were evaluated on can be expressed as follows: given a channel that is open now, and given public gossip data of the network, predict the state of the channel (open, cooperatively closed or force closed) 180 days later. The models were trained on past events from gossip data covering the period from June 9, 2022, to October 14, 2024.

What they found is none of the models was able to accurately predict the state of a channel. Even the model that did best (the MLP model) achieved quite low predictive value, and interestingly this model didn't have graph knowledge, only node gossip data and no channel data passed to the model. Additional analysis helped cement the finding that topology is a very weak signal when trying to predict channel closure, and that the best publicly available signals are nodes' last connection time and past history of channel closes. The main drivers are hence behavioral, and it is likely that only access to private routing data (including forwarding failures and delays, depleted liquidity, etc.) could lead to accurate predictions.

---

That's it for last week. Thank you so much for reading this far, and until next week!

https://stacker.news/items/1494883

Footnotes

1. In theory, it would be feasible to have only one hodl invoice that pays the buyer and goes through the coordinator, for example using blinded paths. The coordinator waits until the seller has confirmed reception of the fiat payment before forwarding the payment to the buyer, in which case the coordinator never holds the funds since only the buyer knows the preimage. If the buyer never sends the fiat payment, the HTLC chain between the seller and the coordinator expires without ever reaching the buyer, and the seller gets their funds back at expiry. ↩

2. Note that in the context of a quick P2P trade such as on HodlHodl, the multisig VTXO will most likely be in a preconfirmed state (as opposed to a settled state). This means that there are some trust assumptions for the Arkade provider to behave honestly. ↩

3. Hodl invoices also have the drawback of locking up liquidity in channels until the payment settles or expires. Big, frequent or long-lived hodl invoices can hence in some cases degrade the routing performance of the channels they go through. ↩