Welcome to your weekly summary of noteworthy news and developments in the Lightning Network ecosystem. Last week the Boltz team released some of what they had been cooking in the past months, Alby shipped multiple relays support for their Hub's Nostr Wallet Connect features, and cluster mempool got merged to Bitcoin Core!

The Boltz team shipped last week with releases to both Boltz' backend and Boltz' client.

The backend release is a huge one, featuring an impressive list of bug fixes, new features and improvements. Among all these niceties, here are a few ones I delved into a bit more.

Up until now, Boltz offered a rescue endpoint for refunding submarine swaps (swaps that move funds from on-chain to Lightning) even when the client had lost its local swap data, by using the xpub to rescue funds. This endpoint is now deprecated and replaced with a restore endpoint, which does the same thing but also supports claiming funds using the appropriate preimage, as long as said preimage was derived deterministically using Boltz' method. It is hence now possible to refund failed swaps or resume still ongoing swaps using only a seed phrase, referred to as the "Boltz Rescue Key". On Boltz' web app, this rescue is generated and persisted locally (in the user's browser) and should be backed up.

One of the dominant usages of Boltz nowadays is inside wallet apps such as Aqua or the Bull Bitcoin wallet, where it's abstracted away from users. The core idea is to enable users to send and receive on Lightning without ever running a Lightning node. Instead, the user's balance is kept on-chain (e.g. Bitcoin or Liquid) at rest, and sending or receiving to or from Lightning involves a swap through Boltz. With the increased popularity of such wallets arose the opportunity to simplify the payment flow in some cases by removing useless swaps.

For example, if a user of Aqua wants to pay a Bull Bitcoin user, then the naive flow would involve two swaps:

What if, instead of this convoluted route, the payment could be a simple Liquid send?

Since the lingua franca of all these wallets is Lightning, they use Lightning invoices for payment requests. Simplifying the payment flow hence requires passing extra data inside the invoice to help wallets figure out the payment could be made directly on Liquid. To do so, Boltz introduced Magic Routing Hints (MRH) back in February 2024. The core of the idea is to encode some data inside the Bolt11 invoice's routing hints, which wallets can then leverage to decide if the payment can be made directly (or with fewer swaps).

Today's release further simplifies this management for wallets by exposing a new websockets endpoint that watches payments to the final receiving address (e.g. Liquid on-chain address in Bull Bitcoin). This helps the receiving wallet detect that the incoming payment was made directly and not through a swap, but it remains the wallet's responsibility to then verify that the payment was indeed made (i.e. wallets should not blindly trust Boltz' backend).

Speaking of Boltz, they got the upcoming release of Core Lightning (CLN) named after them, probably since their big and heavily used CLN node revealed some improvement directions for the open-source Lightning implementation. How cool is that? But we'll cover this new release in greater details when it's fully out...

The Alby team shared their thoughts on what a Nostr Wallet Connect (NWC) "suspendable signer" could look like. Taking a step back, the notion of "suspendable Lightning node" is implemented by solutions such as Greenlight, Lexe or Money Dev Kit (which we covered last week). The core idea behind these solutions is to offer users a self-custodial Lightning experience without all the fuss of running a node. In Greenlight, the user's node runs in Blockstream's cloud but the underlying keys remain on a user-controlled device (e.g. their phone) ; in Lexe the user's node runs inside a Tusted Execution Environment (Intel SGX) ; and in the MDK the node runs inside the user's web app (MDK users are typically developers). In all cases, hosting costs (for the provider in Greenlight and Lexe, for the user in the MDK) are reduced by "suspending" the node when it's not in use and "waking it up" when it needs to receive or send a payment. This "wake up" feature typically relies on the provider acting as a Lightning Service Provider (LSP).

In their article from last week, the Alby team explores how things could be taken even further by stripping as much things from the "suspendable node" as possible, thus turning it into a "suspendable signer" that doesn't need to manage channels. One of the motivations behind this is to reduce the operational costs of Alby Hub instances hosted inside Alby's cloud, which currently run 24/7. Building such a stripped-down signer would likely mean connecting to Spark or Ark entities, which would operate a Lightning Node on behalf of multiple users, but with security and privacy tradeoffs compared to each user running their own node. Therefore, I'm not sure it actually makes sense to look at integrating Spark/Ark though the lense of cloud compute cost reduction, since the benefits seem marginal compared to suspendable Lightning nodes, and the real cost benefits of Spark/Ark lie in the mutualization of channels (which is still an avenue for cost reduction, just not strictly related to compute).

Alby's article nonetheless contains some very interesting considerations around the integration of NWC in suspendable nodes/signers. Indeed, one of the issues is that NWC requires websockets, hence a persistent connection, incompatible with the notion of "suspendability". I think an interesting solution, explored but not found fully suitable by the Alby team, would be to double the NWC interface with an endpoint for short-lived HTTP connections that could be used to wake up the node. Through standardization, this could allow users to choose across different LSPs, that would each be able to issue "wake up calls" for receiving incoming payments¹. But that's easier said than done, especially the standardization part.

In v1.21.0 of the Hub, Alby also introduced support for multiple relays. This means NWC messages can be sent through a backup relay if the main relay is down, and allows Alby Hub self-hosting users to rely on their own relay instead of Alby's if they so see fit. Right now relay configuration isn't available directly in the UI, but can be changed through the RELAY environment variable.

The cluster mempool pull request got merged into Bitcoin Core last week! After 2+ years of hard work (only counting from when the original pull request was opened in October 2023), it completes this new mempool implementation which partitions a node's mempool into fixed-size clusters that are sorted by fee-rate. The goal is to make transaction selection more tightly aligned with economic incentives, i.e. ensuring miners running Bitcoin Core always produce the block paying the highest total fees, given a set of transactions eligible for inclusion into the block.

However, it comes with new rules, such as the cluster size limit, making the CPFP carve-out exemption useless since new transaction pinning vectors are now available. Luckily, ephemeral anchors and 0-fee channels have been rolled out in the meantime and are more and more broadly available across Lightning implementation, as well as part of the Lightning specification now that 2 compatible implementations support them. With CPFP Carve-out going for the exit, Lightning node runners should gradually migrate to ephemeral anchors.

That's it for this week. Thanks for reading this far! If you have any comment or feedback, please do share them, I'll read them all. Until next week!