Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week was a big one, with many many exciting things, ranging from some thorough Lightning economics research, a proposal for public fraud-proofs in LSPs contexts, an LND release, and much more!

Whales ExchangeWhales Exchange

As we covered back in January this year, Electrum supports submarine swaps between on-chain and Lightning. It does so with a decentralized infrastructure where every Electrum runner can opt-in to become a swap provider, with the discovery and coordination between providers and clients performed via Nostr.

This is all great and very exciting, but until now a limitation was that you'd need to run Electrum in order to easily access this submarine swap "marketplace". This gap is now bridged thanks to Whale's Exchange. This new open source project leverages Boltz web interface^[1] to serve Electrum swap providers, letting you initiate a swap with a decentralized provider, but through Boltz' seasoned interface, and hence with any Lightning wallet you'd like.

X Announcement

Public Fraud Proofs for Just-in-Time ChannelsPublic Fraud Proofs for Just-in-Time Channels

Speaking of Electrum, its creator Thomas Voegtlin published a paper on public fraud-proofs for Just-in-Time (JiT) Lightning channels.

Before we dive deeper, let's quickly recap the trust models around JiT channels. As the name implies, a Just-in-Time channel is a channel opened by a Lighting Service Provider (LSP) to a user when a new incoming payment to the user necessitates the deployment of inbound liquidity to them. For example, when a Phoenix user receives their first payment, ACINQ (the company operating the Phoenix wallet) opens a channel with some enough liquidity to accommodate the payment, plus an extra cushion to handle a bunch of future payments.

There are 2 parallel actions going on in this scenario, that can't be done atomically:

• the LSP must publish the on-chain transaction funding the channel, and
• the user must reveal the incoming payment's preimage to the LSP, in order for the Lightning payment to settle.

The trust model changes depending on which action is carried out first:

• if the LSP publishes the transaction first, they trust the user to then reveal the preimage. If the user doesn't, the LSP will have lost some funds to mining fees and locked funds for some time (since they need to force close the channel) ;
• if the user reveals the preimage first, they trust the LSP to indeed open the channel and forward the payment. If the LSP doesn't, the user loses the amount of the HTLC.

The JiT Channels specification indicates that LSPs should default to the LSP-trusts-client model, with the option to switch at any time, for example if they're under attack. However, in scenarios where the user starts using the channel (and reveals the preimage) as soon as the funding transaction is published (zero-conf, a.k.a. "turbo channels") the user still needs to trust the LSP not to double spend the channel funding, so the user-trusts-LSP model would make sense in that case. Under this model, Voegtlin's proposal aims at producing independently verifiable fraud proofs that users can produce should the LSP misbehave.

The core idea is to have the LSP produce a "signed promise" that they will open a JiT channel because there is a specific incoming payment to accommodate. They do so by signing a message that commits to:

• the UTXO they'll use to fund the channel,
• the transaction hash (txid) of the funding transaction,
• the payment hash (i.e. the hash of the preimage),
• a block height n, at which this promise expires.

The LSP can produce multiple signed promises, for multiple UTXOs, if the funding transactions has many inputs.

The LSP also shows the unsigned funding transaction to the user, allowing them to verify that the specified UTXOs were used as an input, that the txid matches, and that the expected payment amount is pushed to their side of the channel. With all this verifications done and the promises signed by the LSP, the user can now reveal the preimage.

At this point, if the user suspects something fishy (e.g. the LSP is taking too much time to open the channel, or they catch the LSP double spending some of the pledged UTXOs) they can reveal the preimage by publishing it on-chain in an OP_RETURN. Using OP_RETURN offers 3 important properties:

• non deniability, the LSP is expected to monitor the chain for OP_RETURN containing such preimages^[2] so they can't argue that they don't know the preimage ;
• timestamping, proving that the preimage was published before block n
• persistence, this published preimage constitutes a fraud proof, so it's important that it remains publicly available.

By sharing the signed promises produced by the LSP, the user can prove that the LSP didn't fulfill their engagement. With this signed pledges and the OP_RETURN data, anyone can independently verify the fraud proof.

StackerNews Discussion

Lightning Economics ReportLightning Economics Report

Zeus and Axiom published a thorough report on Lightning economics, highlighting how Lightning uniquely positions Bitcoin as a productive asset. Here are a few key points, pertaining to the report's development:

• professionally managed Lightning nodes currently exhibit around 5% returns on capital, doped by the tremendous capital velocity of Lightning, where the same bitcoin deployed in a channel facilitates the routing of at least an order of magnitude more bitcoins in both directions, leading to this impressive counterparty-risk free rate despite relative low per-payment fee rates. In other words, while other industries achieve similar returns through leverage, Lightning reaches this mark through velocity alone ;
• this velocity gains only apply to actively/professionally managed nodes that deploy liquidity where it will be used, and adjust fees depending on local competition ;
• Lightning turns bitcoin into a productive asset without sacrificing any of its underlying properties: no bitcoin is destroyed (it's only transferred, as fees, from users doing payments to routing nodes) ; no custody is relinquished (node operators remain fully in control of their coins, with the always-available on-chain exit option) ; fees are paid in the productive asset itself and hence compound to future gains ; inevitable centralization pressure into a hub-and-spoke model, while reducing resilience and inducing fragility, does not erode Bitcoin's inherent scarcity, cannot lead to fund capture, and the network can recover relatively quickly since recovered (or external) funds can be deployed into new channels that route around the failure points.

The above is a quite condensed summary of Zeus and Axiom's paper, but I hope it conveys one of its main points: unlike other "yield-earning" crypto protocols or Bitcoin-centered financial engineering strategies (wink wink), Lightning enables Bitcoin holders to earn a substantial return on an asset that they'd otherwise usually treat as unproductive, with no counterparty risk and low and rapidly diminishing technical risks, all while fostering Bitcoin's core characteristics of scarcity, trustlessness, permissionlessness and openness.

If you want a slightly easier point of entry into this 30 pages report, here's a version with my own highlights.

StackerNews Discussion

LND v0.21.0-beta Release CandidateLND v0.21.0-beta Release Candidate

The first release candidate for the v0.21.0-beta of LND has been published. As the Lightning Labs team explains, this release "ships basic onion messaging support, finalizes production simple taproot channels, and continues [LND's] journey of migrating LND's data stores to native SQL". Let's expand a little bit on each item:

• Onion Messages (OM) are messages routed across the Lightning Network, a bit like payments but without the need for a channel between two nodes. Their primary use case is the coordination of invoice delivery with Bolt12 Offers. We covered Onion Messages coming to LND very soon last week, when reporting on a discussion around Onion Message Jamming ;
• Simple Taproot Channels are supported by (at least) LND and Eclair, and are channels that use Taproot and Musig2 to fund channels and build their commitment transactions ;
• LND's database migration from a key-value system to a real SQL database is a long-lasting effort to improve the implementation's performance. The initial database design has indeed proved to negatively impact large scale nodes, requiring frequent database compaction.

Pretty big release!

Core Lightning v26.04Core Lightning v26.04

Core Lightning shipped v26.04. As we covered when the release was still at the release candidate stage, this release notably brings splicing out of the experimental branch, improves pathfinding and payment reliability, and mitigates traffic analysis on messages exchanges between peers.

Quick StrikesQuick Strikes

• Spiral announced a grant for Nishat Bansal, supporting his work on improving Lightning security, notably through fuzz testing across implementations ;
• Austin, who's also a Spiral grantee, released a new module on his Programming Lightning technical education website, dedicated to the noise protocol and how it's used in Lightning ;
• LQWD Technologies released SaturnZap, an open source lightweight non-custodial Lightning wallet for autonomous AI agents, built on top of the Lightning Dev Kit. The node connects to an Esplora backend in order to get chain data, and uses LDQW as its default LSP ;
• Zeus v13.0.0 was released. See our coverage of the beta ;
• speaking of Zeus, they completed a SOC 2 Type II audit, which is often a requirement for working with enterprise and institutional partners. This will probably help them offer their white glove Lightning infrastructure service to more, higher stakes clients.

That's it for last week! As always, thanks a ton for reading this far, and until next week!

1. It's actually a fork of the boltz-web-app. ↩

2. To improve scanning, the OP_RETURN would be prefixed, making it easy to identify. ↩