Latest Strikes 43 - June 26-July 2nd 2023

Welcome to the 43rd issue of Latest Strikes, your weekly recap of all the great things happening in the realm of Lightning! Funny enough, 43 is a bit of a special number: it's the greatest number that is not a McNugget number. That is, any number above 43 can be expressed as a linear combination of 6, 9 and 20. Interesting? Yeah, I'm not so sure either. Soooo, let's see what happened in Lightning last week instead, am I right? Grab your french fries and your McDonald's hat, we're gone for a new wrap!

Privacy note: links to Twitter posts don't redirect to Nitter instances in this issue, because Twitter's rate limiting strategy broke most (all?) Nitter instances. For now, those links are plain twitter.com links.

Ecosystem

Ambucks

Amboss launched a prepaid credit system that can be used to buy channels in the Magma marketplace. This opens up the possibility for Lightning newcomers to buy their first channels via credit card. These credits, called Ambucks, can indeed be bought with Bitcoin or fiat with a credit/debit card payment.

However, this new feature also raised concerns around privacy. Indeed, linking one's personal identity (available to Amboss when paying with fiat) to one's Lightning node is a bad idea, and affects the whole network's privacy.

Lightning In The Pocket

Lightning is coming to Pocket! Pocket is an app where users can buy Bitcoin with a simple bank transfer, and no KYC (apart from the information the bank transfer itself leaks). If a user sets up a recurring transfer to Pocket, they can buy Bitcoin automatically every week or month, a practice known as DCA (Dollar Cost Averaging). Recently, Pocket acquired Bitkipi, which brought a real self-custodial Bitcoin wallet into the app, where the bitcoins go when they're bought and where the user is in full control of their keys.

The launch of Lightning capabilities into the Pocket app seems imminent, first with Phoenix withdrawals, and later on with support for withdrawing to one's own node, with a channel opening service if a new channel is required to process the payment. Now, frictionless self-custodial DCA is way harder to achieve on Lightning than it is with on-chain Bitcoin, because the receiver has to be around when the payment is sent. Here are a few ways this could be achieved, with varying complexity, and which ultimately depend on the end-user setup.

• When a bank transfer is received, lock the exchange rate and notify the user (for example via email, nostr or push notification), asking them for an invoice for a given amount. The user creates an invoice with the Lightning wallet of their choice, then heads to the Pocket app and pastes the invoice in the field presented to them.
• Using mechanisms such as LNURL-Pay or Bolt12 Offers to send the Lightning payment without having to notify the user by asking for an invoice directly to their node. This method is elegant but faces several problems:
  • the user needs to have a node online to answer the invoice request, which tends to rule out mobile nodes ;
  • as of now, the LNURL server can cheat and answer with their own invoice, thus stealing the funds. Of course, this will be noticed quite quickly, but the funds are still gone. As we discussed in a previous issue, this can be mitigated when the sender knows the receiver's node public key, and can hence ensure they're only paying invoices to the right node. However, this is a bit backward with current efforts deployed into enhancing receiver privacy on Lightning,
  • on the other hand, Bolt12 will eventually address LNURL limitations, but is not widely deployed on the network yet ;
• By using spontaneous payment (a.k.a keysend) the service could send funds straight to the user's node simply by knowing their public key, but I feel like the lack of proof-of-payment could be an issue for this specific use case ;
• Integrating a self-custodial Lightning wallet straight in the app and use notifications to wake the app when needed would be a very nice solution, but I'm not entirely sure the feasibility of using push notifications to gain enough CPU time to perform Lightning operations is demonstrated yet.

The first option is by far the easiest, and also the only one that is quite agnostic with respect to the user's setup. They could be using a custodial mobile wallet (such as Wallet of Satoshi), a non-custodial one (such as Phoenix), or have their own node: it would still work. From what I've heard, that's also the one the Pocket team is going with, at least for now.

Wallets & Tools

VLS Beta Release

The Validating Lightning Signer (VLS) is finally released in Beta! The VLS software aims at improving Lightning nodes security by segregating the signing component (including the private keys) from the rest of the node, while still ensuring the signing module only signs legitimate requests. This constitutes a very necessary infrastructure tool for Lightning, which will help node operators and developers increase security without having to create their own systems [like Acinq did].

This beta release indicates that the VLS team is confident enough with their software for it to be tried out by developers on testnet, or with limited funds on mainnet. It also follows an independent security review conducted by Antoine Riard back in January. With this beta release, we're one step closer to having fully validating signers running in production, and a much more mature Lightning industry. Big news!

Real Time Monitoring In BoltObserver

Speaking of maturity, BoltObserver released sub-60 seconds notifications in their node monitoring offering. If anything goes wrong, you can now receive alerts quicker than ever: less downtime, better revenue/security/reputation. Nice!

Breez SDK

The hype around the Breez SDK reached a new top last week with Jesse de Wit showcasing how easy it is to get started and add Lightning payments capabilities to a mobile app.

Blixt Update

There's a new Blixt release, bringing improvements to the synchronization of the channel graph with a new feature called Speedloader. This opt-in module helps ensure that the Blixt node gets the latest view of the channel network on startup, which helps pathfinding by providing more accurate data. Indeed, the channel graph consists of all the channels known to a node, with their respective capacity, fees, HTLC acceptors, and so on. The graph evolves quickly as channels open and close, and as certain parameters (fee, maximum payment size, etc.) evolve. All this changes are advertised on the gossip communication layer of the protocol, and that's how nodes of the network catch up with them. When sending a payment, a node then uses its graph to find a suitable route to its destination. Hence the paramount importance of having up-to-date data, to avoid payment failures or using suboptimal routes.

This update also brings support for zero-conf channels and hodl-invoices.

Spec & Implems

Core Lightning

Core Lightning v23.05.2 is out and consists essentially in bug fixes. It is a recommended update for anyone running version 23.05 or above.

Equalizing Packet Size

Zman proposed to standardize the size of IP packets exchanged between Lightning peers. Indeed, although communications between peers are encrypted using the Noise protocol, it is still theoretically possible for an attacker to observe the sizes of packets exchanged by nodes and use this information to guess which message they exchange. On a wide-enough scale, this could (theoretically) be used to infer the exact route followed by a payment.

Always sending packets of the same size (filling up with padding if necessary) would mitigate this attack vector and help further enhance Lightning's privacy. As of this writing, nobody answered Zman's proposal on the mailing list.

Keeping The Specification Tidy

There's an ongoing cleaning work initiated by Rusty Russel on the Bolts repository, which is akin to the Lightning Network's specification. This cleanup notably consists in the "removal" of some features that used to be optional, but are now so widely implemented that they don't need to be explicitly advertised by nodes anymore. This is the case, for example, for the gossip_queries feature, which allows node to specify to their peer what kind of gossip data they're interested in. As pretty much all the nodes on the network now implement this feature by default, it doesn't make much sense anymore to discuss with a peer whether they support this feature or not when connecting to them.

Before you go

That's it for this week! But before you go: we also released the second post of our deep dive on Discreet Log Contracts (DLCs). Go give it a read!

Closing Bit

L'odeur du sang, la peur des flammes
La fumée noire d'un bus qui crame
Les cris, l'éclair, la pluie, poussière
La lueur bleue des réverbères

Le monde entier qui s'écoule là
Charié par le courant du Port
Une course aride, pas de temps mort
Et un gamin, qui s'écroule là.