Latest Strikes 66 - December 4th 2023-January 7th 2024

Hey there, Lightninger! Welcome to the very first issue of Latest Strikes on this side of New Year's Eve! I know it's been a while since the last issue, but that's because we (at LN Markets) are cooking you some very special treats for this new year. Don't worry though, you favorite Lightning newsletter is back with its weekly dose of thunderous news!

Ecosystem

More OpenSats Grants

In mid-december, OpenSats issues its third wave of Bitcoin Grants. Grantees include:

• Clams, an interface for Core Lightning nodes, with a very nice UX and which uses commando to establish a secure connection with the remote Core Lightning node ;
• Validating Lightning Signer, which aims at improving the operational security of Lightning nodes by segregating the signing (and hence the private keys) from the rest of the node ;
• Lightning Gateway for Fedimint, which is a crucial part of Fedimint, as it connects mints to the outer world, through Lightning ;
• Pickhardt Payments plugin for Core-Lightning, bringing this alternative routing algorithm to Blockstream's implementation of the Lightning Network ;
• BitBanana, the remake of Strike's now deprecated Zap app, which lets you remotely control your LND node.

River Link

River released a fantastic new feature called "River Link", enabling River users to seamlessly send Bitcoin to anyone in the world. Instead of asking the recipient for an invoice or an address, the user can share a link with their recipient (via any messaging app, email, avian carrier, etc.). Visiting the link, the recipient can then claim the sats, with or without a River account (i.e. to an external wallet), via on-chain or Lightning, paying only the network fees.

Amboss Ghost Addresses

Amboss released a new feature called Ghost Addresses, which is essentially a novel way for Lightning node operators to receive payments to a Lightning Address without having to host a web server themselves. The way it works is:

• a node runner can claim a Ghost Address from Amboss (currently only through Thunderhub version 0.13.29 and subsequent, which also means it currently only available to LND nodes),
• from then on, anyone trying to pay this Ghost Address (typically <username>@ghst.to) will fetch an invoice from Amboss API and try to pay it. The invoice is generated by Amboss and points to a fake, virtual node as the destination of the payment. As the destination node doesn't exist, the sender cannot find it on the network. However, Amboss will also add a routing hint in the invoice, which instructs the sender to use the node of the actual Ghost Address user as a last hop before the (fake) final destination,
• the Ghost Address' user node is therefore instructed to route a payment to the fake node. It recognizes that it corresponds to a Ghost payment for them, and requests the corresponding preimage from Amboss API. Upon receiving the preimage, the node can then claim the funds. To the sender, it is as if the funds were claimed by the fake node, while the actual recipient received them with Amboss' assistance.

This construction is interesting because it's a nice complement to the existing Lightning Address bridges (such as satdress servers like lnaddress.me). This bridges let you connect your Lightning node using an invoice macaroon (or equivalent). When someone tries to pay you on such a Lightning Address, the web server will request an invoice from your node, and serve it to the sender.

To put it in a nutshell, Ghost Addresses are essentially a Lightning Address bridge where the invoice generation is performed by the bridge. The main drawback is that it adds one additional trust assumption (that the bridge will release the preimage when asked by the recipient, which seems like a fine trust assumption for this use case), with the added benefit that the node runner doesn't need to give the bridge any macaroon/rune. However, since most (all?) implementations support fine-grained permissions (or at least an invoice-only macaroon which can only asks the node to generate invoices), the benefits seem limited. Privacy-wise, the bridge learns the same amount of information in both cases, and the recipient's private key is made slightly more private with Ghost Addresses.

Wallets & Tools

Critical Vulnerabilities In BTCPay Server's LNBank Plugin

In December, the LNBank plugin for BTCPay Server was hit with two successive vulnerabilities, of which at least the first one was actively exploited - that's how it was discovered, which led to users funds being stolen (amounting to huge amounts for some).

LNBank is a plugin for BTCPay Server which essentially enables the administrator of a BTCPay Server instance to become a custodian. Other people can create an account on your instance, deposit and withdraw funds, all using your own existing Lightning infrastructure (i.e. your channels).

The first vulnerability was a race condition on successive withdrawals from the LNBank, where a malicious user could withdraw more than their balance by submitting multiple withdrawal requests, tricking the software into accepting the subsequent requests while the first one was still being processed and not yet recorded on the database. The vulnerability was quickly fixed in version 1.8.9 of LNBank, but had already been exploited, notably leading to the loss of around 4 BTC for Hugo Ramos (donations are welcomed at hugo@fyoumoneypod.com).

Unfortunately, a second vulnerability was disclosed shortly after, leading to an another emergency patch (v1.9.2), which also disabled the withdrawal feature altogether for good measure. Dennis, the developer of the LNBank plugin, also took the decision to completely sunset LNBank. An option which he was already considering after the first exploit, but which was ultimately confirmed after the second vulnerability (which is yet to be disclosed).

This is a reminiscence of another vulnerability that was spotted in LNBits back in June last year, and which could also enable malicious users to withdraw more than what they really owned. Building safe custodial accounting systems on top of Lightning nodes is hard, as both cases show.

Zeus Update Brings Standalone PoS, Nostr Contacts & Persistence Mode

The beta version of the new Zeus release v0.8.1 was published last week, bringing:

• importing Nostr contacts ;
• a standalone Point of Sale, with inventory management (e.g. add/remove products and price them, review sales, etc.)
• persistent LND node (which we called for in November last year after a similar feature was released in Blixt), which means that the Lightning node embedded into the app can now run even if Zeus is closed, enabling instant redemption of Zeus Pay incoming payments! No more hodl invoices ⚡️

Fedimint & Mutiny

Mutiny also shipped a very nice feature at the end of last year with the integration of Fedimint (still in alpha though)!

Fedimint is a protocol for federated e-cash mints, where instead of having only one custodian responsible for holding the funds of the chaumian mint, this responsibility is shared across a federation of custodians (a bit like in Liquid). Fedimint's integration in Mutiny brings an hybrid mode where, while self-custodial Lightning will always be preferred when possible, e-cash will be used in some cases, such as receiving just a few sats when the Mutiny user doesn't have any channel yet. We already covered the subject back in September last year, when Ben from Mutiny showcased an early version of this new feature, detailing the rationale behind using e-cash when it is now economically viable to use Lightning.

Case and point, when it comes to custodial solutions, a decent e-cash mint with a (or several) Lightning gateway(s) seems way better than a custodial Lightning wallet, both privacy-wise and in terms of proving what you're owed by the custodian.

Electrum Lets You Send Change To Lightning Channel

Electrum version 4.5.0 brought interesting new features to the Lightning component of the wallet, such as support for hodl-invoices and a new flow for submarine swaps which enables users to send the change of their on-chain transaction to one of their Lightning channels. A pretty nice way to refill a channel without any additional cost.

Tooling Updates

In the past weeks we got a few noteworthy updates to some of our favorites Lightning node management tools:

• RideTheLightning changed how it connects to a Core Lightning node, from the previous c-lightning-rest connector (now deprecated) to using Core Lightning's native CLNRest plugin ;
• chantools, an awesome tool notorious for saving LND users days in countless occasions, now supports pulling on an anchor to bump the fees of a channel force close transaction when those were set too low. Comes in quite handy in times of frequent sudden on-chain fee spikes ;
• Lightning Terminal now supports batching channel opens, allowing node operators to save on fees by opening many channels in only one on-chain transaction.

Alby's Rocking End Of Year

The Alby team had a rocking end of the year!

Notably, they're one of the winners of BoltFUN's very first awards with Bitcoin Connect. Bitcoin Connect is an amazing tool that makes it fairly easy for developers to enable their users to seamlessly connect their favorite Lightning wallet to a website and start sending and receiving payments. It uses WebLN under the hood as a common interface to all kinds of Lightning wallets, be it an already WebLN-based wallet (such as the Alby extension), or a wallet using other communication protocols such as Nostr Wallet Connect (NWC, used to connect to wallet such as Alby or Mutiny) or Lightning Node Connect (LNC, an awesome way to connect to an LND node).

At LN Markets, we definitely recognize how handy such a framework can be. We've developed connectors for WebLN, LNC and more in-house, allowing users to seamlessly interact between LN Markets and their Lightning wallet/node, but having an open source connector available is game changing. Which I think is shown by the number of websites that have already taken advantage of Bitcoin Connect instead of reinventing the wheel, such as Zapstream, Nostrudel or Habla for example. Of course, it's still very much niche, but who knows, maybe that'll be one of the powerhouses of the web's Lightning Renaissance?

On a different note, the Alby team also added Liquid support (which leverages the Master Key feature they released a few months ago) and NWC connection in their extension, and started to limit inscriptions to their custodial offering as they focus more and more on building self-custodial solutions. Very nice to see, in a period where self-custodial Lightning is increasingly being declared "too hard for the masses" and seen as a business-to-business use case. While there are definitely challenges to an easy-to-use Lightning self-custody, both behind and ahead, I think it's still a bit early to declare ourself vanquished.

Spec & Implems

Maypoles

Clara Shikhelman (from Chaincode Labs) published an interesting paper describing a protocol aiming at strengthening the Lightning Network's topological features, while also reducing channel management costs for "merchants nodes".

For efficiency and reliability reasons, the Lightning Network is clearly trending more and more towards an hub-and-spoke topology, where a "few" major nodes have many channels and are very densely connected (the hubs), while the rest usually have very few channels, and often just one which they share with a hub (the spokes). While this topology entails some benefits, it comes at the expense of resilience (both to attacks and failures) and privacy. For example, a spoke that is only connected to one node would lose all ability to transact on Lightning should their hub go offline, unless they open a new channel, which could be expensive, especially if they're in a hurry.

The idea of the Maypoles protocol is that each spoke should open two channels with two different hubs. One is their main channel, where they hold the equivalent of a few days worth of transactions, while the second is their secondary channel, which acts as a backup and is also used to rebalance the main channel. In Maypoles, the hub for the secondary channel is suggested to the spokes by the hub of their main channel, and hubs know ahead of time that another hub suggested them to their spokes, and reciprocate the recommendation (i.e. they suggest the hub that recommended them to their own spokes). This reciprocity is what ensures that it's almost always possible for a spoke to rebalance their main channel using circular rebalancing, by going through their secondary channel and the channels of a spoke of their secondary hub.

Shikhelman shows that opening two channels per spoke as described in the Maypoles algorithm benefits both the network and "merchant nodes" (which I define as nodes that have high availability requirements - being able to receive and send at anytime, in opposition to "mobile nodes" which go on and off and have weaker availability requirements). A merchant node needs to have enough inbound liquidity in their channel to receive at anytime, or else they could lose sales. Such "High Availability Channels" users benefit Maypoles because, with the right size for their secondary channel, it allows them to reduce their channels costs (both in terms of on-chain fees linked to channel operations, and opportunity costs associated with having funds "locked" in a channel). They also get enhanced privacy, since their activity now goes through two hubs instead of one, which is even stronger with Multipart Payments^[1]. On the network side, the benefits of Maypoles are striking, especially when applied to the current topology of the network, increasing decentralization among the hubs and strengthening the whole network's connectivity (e.g. it's harder for a subset of the network to find itself isolated from the rest). Finally, hubs also have an incentive to implement the Maypoles protocol, because it brings them more routing volume with no added cost.

Maypoles is hence an interesting and practical look at how we can improve on the network's topology, while acknowledging that it will probably largely remain a hub-and-spoke network. It does not aim at creating the "perfect" topology in a sandbox which would be impossible to replicate in the real world due to the decentralized nature of the network. Rather, it tries to define an incentive-aligned algorithm for establishing channels in a way that also strengthen the whole network. Well worth a read!

Scaling Lightning Safely With Feerate-Dependent Timelocks

John Law formally proposed a new innovative way to lockup coins forever in the timechain. Feerate-Dependent Timelocks (FDTs) would extend the current time-based timelocking abilities of Bitcoin with a feerate component, in order to ensure multiparty protocols that depend on timely confirmation of presigned transactions for their security (such as Lightning) are safer when it comes to on-chain congestion and skyrocketing fees.

In Lightning, when a channel is force-closed, the output of the force-closing party is encumbered with a timelock, which gives the other party a time window during which their node can review the closing transaction and, if it's pushing a revoked state, punish the cheating party (or just set the record straight in Lightning protocols that are not penalty-based). However, this mechanism requires the timely confirmation of the justice transaction, which could be hindered during times of high on-chain fees. This could even be used to leverage a systemic attack on the network by a sophisticated entity controlling a huge number of channels.

Hence John Law's proposal - which would require a soft fork - to also take the feerate into account. Currently, the timelock on the force-closing node's output only specifies that they have to wait N blocks after closing the channel before they can claim the funds. The idea is that this N blocks should be enough for the other party to broadcast their justice transaction if need be, and for it to confirm. However, sudden spikes in on-chain fees can render a number N that seemed totally okay just days ago completely useless today. A Feerate-Dependent Timelock would add another condition to the timelock, stating that the force-closing party also can't claim the funds until after a window of K blocks has occurred, starting after the timelock has expired, and during which the median feerate of a percentage of the blocks (say 70%) was below a certain agreed-upon threshold.

In other words, not only does the force-closing party need to wait for the timelock to expire but, if fees are sustainably higher than a certain threshold, they also need to wait until the on-chain fees cool-off for a bit, which gives the other party enough room to get their justice transaction into a block.

Speaking of soft forks and scaling Lightning, I highly recommend giving this piece by Ben Carman a read. It delves into Lightning limitations (in terms of liquidity management, user experience - offline receive anyone?, and scalability). Ultimately, as Ben highlights, Lightning's scalability is limited by the fact that while "[it] lets us move payments off-chain (...) what it doesn't do is let us move ownership off-chain". That is, having multiple users control the same UTXO, but with more flexibility than what N-of-N multisigs allow. Covenants can help us achieve just that (and hence, multiparty channels, better statechains, Ark, etc.), but have been at the heart of heated debates for years. What's certain, however, is that the tremendous positive impact they could have on Bitcoin's vertical (i.e. "in layers") scaling is now more and more obvious.

Closing Bit

Deux mille seize blocs ont coulé sur mon pont
Je reste au fond du lac couché sur le limon
Que forment avec moi les avortons sombrés,
Coulés par le fond, dans un oubli forcé.

Les courants ont forci et nous n'avons pas su
Dans les temps impartis parvenir à bon port
Cette route rêvée par quelque armateur fou
Ne sera donc jamais qu'un inutile accord.