Latest Strikes 64 & 65 - November 20th-December 3rd 2023

Hey there, Lightninger! Welcome to a special edition of Latest Strikes, your weekly recap of all the latest news in the Lightning Network ecosystem. Why is it special? Well, as you may have noticed, there was no Latest Strikes issue last week. Instead, this one will cover the last two weeks, and then we'll be back on our weekly schedule! This also means it's a bit of a biggy, but I tried my best to remain laser-focused on what I found the most interesting in the last two weeks load of news, innovations and - yes, as always, drama. Let's unwrap all that together, shall we?

Ecosystem

On Lightning And Regulation

The regulatory topic invited itself to Lightning two weeks ago, with the Nodeless payment processor forced to shut down in Canada, and Wallet of Satoshi exiting the US market.

While Nodeless creator UTXO shared some details regarding the shutdown, explaining that the business is currently being investigated for "illegal money transmission" (e.g. without a license), Wallet of Satoshi remained more vague and only described that they removed their app from the US application stores and will not serve US customers in the future.

This new regulatory incursion into the realm of Lightning is twofold:

• Wallet of Satoshi probably decided to move away from the US market due to the regulatory cost of being a custodian there (as a reminder, Wallet of Satoshi is a custodial wallet, akin to a Lightning bank where the user doesn't hold their keys and hence doesn't really -i.e. cryptographically- own their coins);
• the money transmitting investigation in Canada is a reminiscence of an old counterargument to Lightning being a decent solution for Bitcoin scaling, where Lightning critics would argue that the very design of the network makes it susceptible to attacks by regulators on the basis that any routing node could be perceived as "transmitting money", and would thus need a license to do so as a business, with all the compliance requirements it carries.

However, Nodeless' case is a bit different, since the payment processing service wasn't performing payment routing per se, but rather acting as a payment processor and a (very) short time custodian: users would receive payments to their Nodeless account, from which it would be automatically withdrawn to the safety of their own wallet seconds later. Strict routing is quite different, since it arguably doesn't involve the router taking custody of the funds at any point in time, and the router could hence be regarded as merely a coordinator between a sender and a receiver (takes this with a grain of salt though, as I am definitely not a lawyer).

Both Nodeless and WoS' hurdles strengthen the case for Uncles Jim, these experienced Lightning users that can devote some time and resources to onboarding their local community (family, close friends, colleagues, neighbors, etc.) to Lightning in a custodial way, until they're ready to take the appropriate steps toward self-custody. Luckily, there are plenty of solutions and tools for a node runner looking to be the temporary custodian of their friends (such as LNBits), and UTXO open-sourced the code of Nodeless a few months ago, so that any node runner can also help local businesses accept their first Lightning payments.

Spiral Renews Grant To VLS Project

Spiral renewed their grant to the Validating Lightning Signer (VLS) project for the fourth time! THe VLS project aims at improving the operational security of Lightning nodes by making it easier to separate the private keys from the rest of the node, and hence have the signing happen conditionally on a controlled, secure device.

Wallets & Tools

10101 Launches Public Beta

10101 launched their public beta! As a reminder, 10101 lets you trade Perpetual Futures (like the ones we have at LN Markets) in a self-custodial fashion thanks to the power of DLCs (Discreet Log Contracts, another of Tadge Dryja remarkable inventions).

The 10101 app hence consists in an LDK-based self-custodial wallet with Futures trading capabilities, which notably enables users to emulate a fiat balance just like Stablesats, but without giving away custody of their coins by sending them to an exchange.

Moar Breez SDK

We continue to see the Breez SDK populating wallets in the wild. The latest is Lipa's consumer wallet, which is a self-custodial wallet using the Breez SDK behind the scene with an emphasis on the spending use case (after all, that's probably the main use case for Lightning). As Breez CEO Roy details, Lipa's goal is to finally address the chicken and egg problem of Bitcoin merchants and customers, and their approach is to make it easier and easier for the latter to find the former and spend their coins in these businesses. A step towards it is the inclusion of the BTC Map map into the Lipa wallet, which is based off OpenStreetMap and allows bitcoiners to easily spot businesses that accept Bitcoin as payment, and in which form (on-chain, Lightning, Lightning-over-NFC, etc.). But there's more to come, and the Breez SDK helps the Lipa team focus on these very much needed features, since a great deal of the Lightning complexity is abstracted thanks to the SDK.

We also got an update regarding the integration of Lightning into the BitBox companion app, through the Breez SDK. An interesting dimension pointed out by the BitBox team is how the SDK's design (the Lightning node runs in the "cloud" while the private keys remain on the user's device) helps create coherent multi-devices experience, with the same Lightning wallet showing up in the app on the computer and on the phone. This cohesiveness permitted by the node running in the cloud was already touted for how it enables several apps on the same phone to share the same Lightning wallet, but the BitBox team just takes it one step further with a multi-device experience. Which could prove pretty useful in a variety of situations, and notably in brick-and-mortar businesses where several employees share several payment terminals.

Another Blixt Release

Version 0.6.9-420 (nice!) of Blixt shipped two weeks ago, building on the Persistent Mode feature we touched on in LS62. It connects with the Lightning Box to enable Android users who activate the Persistent Mode to receive sats sent to their Lightning Address straight to their self-custodial wallet, without the Lightning Box server taking custody of the funds at any point in time.

However, note that this setup is still not trustless, since you trust the Lightning Box server to reach out to you to get an invoice when someone tries to pay your Lightning Address, and especially you trust it not to send one of its own invoices instead, as they could be stealthily siphoning payments that were meant to reach you this way.

If we pair this with the Zaplocker attestations (notably implemented in Zeus) we get the better of both worlds: no more channel-breaking, liquidity-blocking 24-hours-long hodl payments, and a trust-minimized relationship with the Lightning Box/Zaplocker server. Maybe we'll see this match made in heaven some day?

Inbound Liquidity Reports In Lightning Terminal

When it comes to managing liquidity in Lightning, data is everything. Lightning Labs pushed a very nice new feature called "Inbound Liquidity Reports" to their Lightning Terminal web app. As the name conveys, this new tools helps you monitor your inbound liquidity, which is absolutely crucial if you intend to receive payments. Inbound Liquidity Reports essentially let you see whether payments of different sizes can reach you, taking into account the inbound liquidity on all of your channels. What I found especially interesting is the "how much does it cost to reach me?" aspect, where Lightning Terminal shows the estimated fee someone sending you a payment of a certain amount would pay for the last hop on the route. You can then easily see if paying you seems a bit pricy for your customers, depending on the typical amount their sending, and act on that by reaching out to your current channel partners, or opening new channels.

Fedimint and DLCs In Mutiny Soon™?

Looks like the Mutiny team is working on implementing Fedimint for users receiving their first sats while the amount isn't big enough to justify/cover the opening of a Lightning channel ; and DLCs 👀

LNBits Release

LNBits pushed a new release which now lets the administrator of a LNBits instance charge fees from the user on all transactions, either to the external Lightning network or inside the instance. This update also fixes some bugs and adds Alby to the list of available funding sources.

Speaking of Alby, they too shipped some code in the last two weeks, which notably brings more details to the transaction view (e.g. you can now see the preimage of any payment you sent, which can be useful when trying to prove you indeed paid).

Spec & Implems

Core Lightning Update

Core Lightning version 23.11 was released last week, bringing among other things:

• full compatibility between Core Lightning and Eclair for the dual-funding of channels, where both peers contribute funds to the channel opening ;
• enhanced access control through runes thanks to a new rate-limit constraint (e.g. a rune can be set so that it can only be used to issue commands to the node every second at most) ;
• more powerful RPC commands, which notably allow to "check if a [wallet] recovery can be performed without actually doing so, which can be helpful to build robust user interfaces", as it means an app could for example check that the user's seed is correct without actually performing the recovery process.

Liquidity Ads (cont'd)

There were some interesting discussions around Liquidity Ads in the last two weeks. As we briefly explained in LS63, Liquidity Ads are a way for nodes to advertise that they're willing to engage and commit funds to opening a dual-funded channel, directly on Lightning's gossip layer. In other words, it creates a Lightning-native liquidity market, where buyers/lessees purchase (or more accurately, lease) Lightning liquidity from sellers/lessors who broadcast their rates on the gossip layer of Lightning.

The first was a call for review by Blockstream's Lisa Neigut (a.k.a. Nifty) on the latest updates made to the Liquidity Ads specification. Notable changes include:

• enabling liquidity buyers to ask for a custom lease duration (instead of a previously fixed one), enabling sellers to price their liquidity more dynamically ;
• providing more granularity on fee caps, for which the lessor commits to not set fees higher than the caps on their side of the channel for the duration of the lease ;
• a discussion on whether it would be possible to punish a lessor that sets fees higher than the fee caps they agreed to, although it seems to be quite challenging due to the high number of different fee values cryptographic commitments would have to sign for ;
• a change in the way the output of the lessor is timelocked during the lease, from a relative CSV timelock that had to be updated frequently, to an absolute CLTV timelock which is set to match the agreed upon duration of the lease, and hence prevents the lessor from closing the channel prematurely and deploying their liquidity elsewhere.

Speaking of timelocks, Bastien Teinturier from Acinq remarked that encumbering the lessor's output with a CLTV timelock could be exploited by the lessee to carry out a liquidity griefing attack. Indeed, the lessee could purposefully ask the lessor to only contribute a relatively small amount to the dual-funding (e.g. the dual-funding transaction takes 1 BTC from the lessee and only 10k sats from the lessor), then send everything they have on their side (e.g. the whole bitcoin) to another node they control, through their channel with the lessor, thus moving all the liquidity on the lessor's side, and then close the channel. This would leave the lessor with a timelocked UTXO (potentially for a month!) they cannot spend, which is liquidity they moved to the other side of another channel and cannot access anymore until the timelock expires. This attack is very cost-effective for the lessee, since they only leased a small amount in the first place (and hence probably paid quite a small fee), but ends up costing a lot (in terms of opportunity cost) to the lessor.

Solutions would be to either drop the whole timelocking of the lessor's output (or make it an optional feature) and rely on reputation to ensure lessors keep their word regarding lease duration ; or a more elaborate, still work-in-progress design where the lessor has two outputs in the commitment transaction, one for the amount of the lease encumbered by a CLTV timelock, and another containing the rest of the lessor's balance on the channel and free of any timelock.

Closing Bit

Le froid a bousculé les cimes des sapins :
Renversée la vapeur, remonté le coucou
Le pays tout entier salue l'hiver souverain.

La sève est descendue aux tréfonds de la terre
Et notre frénésie sur ce lourd tapis vert
S'exalte et se répand en un désordre fou.