Latest Strikes 55 - September 18th-24th 2023

Hey there, Lightninger! Ready for your weekly recap of the latest news of the Lightning Network? Last week got us some interesting stats and case studies, plenty of releases, and an inspiring proposal. Let's dive in!

Ecosystem

Some Efficiency Numbers

The person behind the LNBig nodes ran the numbers and provided us with some very interesting statistics. They computed a capital efficiency metrics for some major nodes they're connected to, which is the sum of the sats sent and received by a given node over 24 hours, divided by the node's capacity over the same period. In other words, how much money flows in and out of a node with respect to how much capital they deployed to make such transfers possible. The higher this ratio is, the better, and of course the holy grail is to reach above 1, where each sat deposited in a channel on average facilitated more than 1 sat worth of economic activity.^[1]

Interestingly, the #1 node on LNBig's ranking (per highest ratio) achieved to move more than 69 BTC (nice!) with a ratio of almost 4. This means they facilitated the transfer of 69 BTC with "only" around 9 BTC in channels, which is quite nice. Also note that the capacity visible to LNBig also takes unannounced channels into account: if you look at this node's public capacity, you'll find a "mere" 2 BTC, which could lead you to believe that this node achieved a whooping 3,500% capital efficiency. It did not.

Those numbers are interesting because, given LNBig's operations size, they could be a good proxy to the average capital efficiency of the network. On top of that, they provide yet another illustration as to why looking at the Lightning Network public capacity through the lenses of TLV is dumb: it doesn't measure what really matters (capital efficiency, or how much deployed liquidity is actually used in "payments") and, even if it did, it would grossly misrepresent it because unannounced capacity must be accounted for. Sorry, DeFi-maxis!

Build The Builders

Fulgur Ventures is organizing another Lightning summit in Italy. The Build the Builders summit will take place in Tuscany, and host cutting-edge conferences, workshops, and social & cultural side events! Last May's Lightning Summit was absolutely epic, so you might want to join this one if you can.

Atomic Swaps

Diamond Hands's submarine swap service just got a lifting, through a joint partnership with Boltz. Diamond Hands uses Boltz' software behind the scene, and the partnership enables the Japanese company to provide all the top-notch features that Boltz has, but with a focus on the Japanese and Asian market (notably through translation and the user interface). In their blog post the Diamond Hands team also describes what they are working on for future releases, which notably includes a PeerSwap integration, which would provide an interesting complementary tool to Lightning node operators.

IVPN

Renowned VPN provider IVPN released an interesting new offering called IVPN Light, allowing users to buy VPN access for as little as 3 hours and up to 30 days, with Lightning, and without the need to setup any account. Just select your configuration, the duration during which you want to access the VPN service, and pay a Lightning invoice.

Starting at 500 sats (for 3 hours), this new service leverages Lightning's micropayments capabilities. It's still a bit of an experiment, so if you feel like trying it out do not hesitate to send some feedback their way (either on GitHub or via their contact page).

Some Interesting Case Studies

Last week blessed us with two very interesting case studies, from two projects we all grew to love: BTCPay Server and the Breez SDK.

• Roy from Breez described how the Breez SDK is being used by Satimoto to enable electric vehicles owners to charge their car in Europe on many different chargers, paying with sats over Lightning. As Roy explains, the choice of Lightning was not ideological, but rather practical: processing fiat payments is a long, cumbersome and costly process ; whereas Lightning is cheap and settles instantly. For end users, the benefit is also very clear: instead of imputing their credit card details into 5+ different apps (one for each charging network), they can now use only one app, to which they don't need to communicate any payment details, and where prices are lower thanks to lower payment processing fees. As to using the Breez SDK, it just made sense as well: the SDK lets developers quickly and easily add Lightning payments into their app, and Greenlight puts the user's Lightning node in the cloud, potentially available to many different Lightning-enabled apps, while the private keys remain safe on the user's device.
• The BTCPay Server team shared some insights following the deployment of Lightning payments in food trucks at the 2023 Baltic HoneyBadger conference. The focus was on ease of use for merchants and customers, so the funds received over Lightning were sent to a custodial Alby account in the first place. Then, every time a merchant's balance reached 100,000 sats, the funds were automatically sent to an external Bitcoin and Liquid wallet, where merchants could receive the funds either as USDT on Liquid, or Bitcoin. Interestingly, the whole setup used existing BTCPay plugins and integration (namely Payout and Prism to withdraw the merchants funds from Alby, and Sideshift to convert the funds to USDT for merchants that did not want to deal with Bitcoin's volatility).

Wallets & Tools

Alby

A new version of the Alby browser extension was released last week, bringing some interesting new features and improvements:

• the receiving side of the wallet got a nice refresh,
• it is now possible to perform atomic swaps between on-chain and Lightning directly from within Alby using Deezy's services, which means you can now send and receive on-chain with Alby.

Zeus

As we covered in past issues of this newsletter, the Zeus wallet has released the first versions of its new embedded node functionality. This means that the wallet, which was initially meant to act as a way to access and use your Lightning node from your phone, now has one additional string in its bow: an embedded Lightning node running inside the app, directly on the user's phone (much like wallets such as Phoenix and Breez for example). Just like those wallets, Zeus provides its users with the services of a LSP (Lightning Service Provider), which makes the onboarding to Lightning easier by providing liquidity when its needed. Notably, the Zeus team is working on integrating LNURL-Withdraw with this LSP feature, which means a new Lightning user could simply scan a QR code to redeem a voucher, and the channel required to receive the funds would be opened automatically. Kinda neat!

Another interesting thing is that the Zeus team can leverage the fact that many current Zeus users already have their own Lightning node at home to enrich this new embedded node features. For instance, you can establish a "trusted channel" (aka hosted channel) between your node at home and the node on your phone. This enables you to still reach the whole network that your big node at home has access to, but from a different node, which means putting less funds "at risk" on your phone (since only the funds held in your Zeus embedded node would be accessible to a thief getting hold of your phone). That's a very interesting development, which could totally obsolete the way Zeus worked previously, where you would connect the app to your big node directly.

Subscriptions In Mutiny

Mutiny added a subscription-like feature, using Nostr Wallet Connect. The wallet already enabled users to connect some services to their wallet with NWC, but each payment required the explicit (i.e. manual) approbation of the user. Now, you can set a budget for each connection, and the wallet will automatically pay any request up to this limit. This new feature can be used to send zaps on Nostr straight from one's Mutiny wallet, but the possibilities are actually much wider: pretty much any subscription scheme could be based of this model, where the user sets up a link between a service and their wallet on their first visit, and the service can then request payments on its own. The payments will then be sent automatically by the wallet the next time the user launches it, transparently and without any further interaction from the user.

That's quite huge, because subscriptions are a quite common flow of the traditional financial world that are quite hard to replicate in a self-custodial world. Well done!

Spec & Implems

Payment Splitting & Switching

Gijs van Dam wrote a very interesting message to the Lightning-Dev mailing list, highlighting his work on an alternative and complementary routing mechanism called Payment Splitting & Switching (PSS). Usually, the route of a payment is entirely determined by the sender, even when using MultiPath Payment (MPP), where the payment is fragmented into smaller chunks that move from sender to recipient along different routes. PSS is a bit like MPP, but at the initiative of an intermediate routing node rather than the sender.

One of the great benefits of PSS is that it takes advantage of the knowledge that a node has of the liquidity distribution inside its own channels. Let's say I'm a routing node, and I receive an Onion packet that says I need to forward a 500k sats payment to Bob, with whom I have a direct channel with 2 million sats of capacity. The sender of the payment assumed that, given the size of the channel, I would probably be able to forward the payment to Bob. Yet, for some reason, I only have 100k sats left on my side of my channel with Bob. Usually, I would therefore fail the payment, and send back an error that says there's a temporary liquidity issue on my side. However, if I'm running PSS, I can try to find another route between me and Bob, that could for example go through another node called Carol. I split the payment in two chunks, one of 100k sats that goes directly to Bob via our common channel, and another of 400k sats that will try to reach Bob through Carol. I'm not certain it will work since I don't know what the liquidity distribution between Carol and Bob is, but since the alternative is failing the payment altogether, that's worth a shot. If it works and the whole 500k sats reach Bob, the payment can then continue its journey across the network, and I am able to collect at least some routing fees, whereas I would have received nothing at all if I had had to fail the payment.

From the sender point of view, it's just as if the payment went through me to Bob. Actually, they don't even know that I slightly changed their route to reach Bob. This has additional privacy benefits, since it mitigates balance probing attacks, where a malicious node can send fake payments to try to measure the distribution of liquidity inside the channels of other nodes. PSS hence hits two birds with one stone, and achieves the not so common perk of enhancing both payment reliability and privacy at the same time. Definitely worth digging into!

Trivia Of The Week

Is it possible to send fractions of satoshis on the Lightning Network?

Closing Bit

C'est l'étendue qui appelle
De son silence notre rosaire
A mesure que le temps s'égraine.