Latest Strikes 63 - November 13th-19th 2023

Welcome back, Lightninger! Last week was a bit noisy, but we'll try to get to the signal! We've got a surge of ads on Lightning, a drama between Greek gods and pirates, interesting discussions around Bolt12 Lightning Addresses, and much more!

Ecosystem

Lightning Ads

The topic of ads on Lightning made a comeback last week, amidst many advertisement being sent to Lightning wallets in the last weeks. The idea is simple: send unsolicited payments of a few sats (either using keysend or Lightning Address) and attach the ad to the payment as a "comment". The exact way the comment is attached to the payment varies between keysend and Lightning Address, but the idea is essentially the same.

The problem comes from the proliferation of such ads, fueled by the development of services such as Satogram, which let anyone send messages to thousand of wallets without having to run their own Lightning node. On the wallet side, solutions exist to mitigate the spam these ads can represent. For example, Zeus and LightningTipBot (a custodial Lightning wallet using a Telegram bot as its user interface) have implemented filters, where low value transactions can easily be hidden, leaving the user unbothered while still letting them pocket the sats. A more drastic approach would be to block small-value transactions altogether, for example by setting the min_htlc parameter of your channels to an amount where you don't consider such payments to be spam anymore.

Ultimately I think it's a quite interesting development, since users can easily tune their wallet's settings to filter the noise while still pocketing the sats, or will be able to as wallets implement this feature. However, the fact remains that this is quite an inefficient marketing method, especially when wallets implement filters, and users can create dozens of wallets to reap the benefits without seeing any ads. I hence expect this fad to retreat, as pushback intensifies and Lightning ads get increasingly filtered from the user view, unless they pay a big enough amount - which might or might not be in line with marketing budgets.

CoopPay

Pouch, in partnership with One Coop Tech, launched CoopPay, a Lightning wallet for cooperatives in the Philippines. Rolled out to the 100,000 members of the FICCO cooperative (the largest in the Philippines), the wallet lets its users send and receive bitcoin and Philippine pesos. While it looks like many other apps we've already seen that bridge Lightning and the more traditional banking/fintech ecosystem (such as Strike or Bitnob for example), what I found particularly interesting here is the positioning. Lightning and Bitcoin can benefit cooperatives in the Philippines, both in terms of fostering the local economy, as well as making it easier to interact with international businesses and customers, or tourists visiting.

Wallets & Tools

Backlash Against Zeus Intensifies

We've got some drama between Zeus et Mutiny last week! It all started when the Mutiny team added a filter on the Nostr Wallet Connect (NWC) interface of the wallet, which is the one used by Mutiny users to send zaps on Nostr without having to leave their Nostr client^[1]. The filter essentially disregarded invoices paying Zeus' LSP Olympus' node in an attempt to protect Mutiny users from unknowingly sending payments that could take a long time to settle, or even lead to costly channel force closes.

Indeed, as we covered here, Zeus' latest feature "Zeus Pay" lets Zeus users receive to a "non-custodial Lightning Address", where trust in the Lightning Address server is mitigated through Zaplocker-style attestations, while the asynchronicity of payments is handled by using hodl payments. This latter is what causes the trouble, this it essentially means that a payment to a Zeus Lightning Address will be pending and freeze liquidity in its route until the recipient's Zeus wallet comes back online, or the payment expires 24 hours later. To make things worse, if the sender of the payment (for example a Mutiny user) doesn't come back online in time once the recipient claims the payment, this could lead to a force close of the channel they used to send this payment, since their direct peer would have no choice but to take the HTLC to the chain to settle it there by using the preimage, of face the risk of the payment being expired and them being defrauded of the amount of the payment.

In other worlds, while Zeus innovative Lightning Address mechanism is interesting, it definitely constitutes for now a poor solution to the asynchronous payment problem, especially when the payment occurs between two mobile users. If a Mutiny user tries to zap a Zeus user, but the Zeus user is offline, they will not necessarily see it and carry on with their day. If the Zeus user later claims the payment in the 24-hours window but the Mutiny user doesn't come back online promptly enough to update the state of their channel with their peer accordingly, the peer will close the channel, and the cost of the closing could be on the user if they opened the channel (not to mention the cost of having to reopen a channel later).

Facing pressure from some users, the Mutiny team later reenabled zaps to Zeus Lightning Addresses, through an optional setting.

Spec & Implems

LND v0.17.1 Is Out!

The first LND minor release of the 0.17.x cycle was published last week! It ships a lot of bug fixes and optimizations (notably CPU performance under heavy mempool conditions), as well as enhancements to how and when LND tries to sweep anchor outputs when a channel is force closed locally. Indeed, LND was previously always "force-sweeping" the anchor (i.e. using the anchor to bump the channel closing transaction fees with CPFP), even when it was not necessary. Now LND will only do so if the situation dictates it (low fees attached to the closing transaction, dense mempool, etc.) and otherwise try to sweep the anchor funds when on-chain fees make it economically reasonable to do so.

Bolt12 Lightning Addresses

Last week witnessed some interesting proposals and discussions around what Lightning Addresses could look like in a Bolt12 world. Notably, Bastien from Acinq shared a thoughtful exploration of the different options at hand to implement a protocol very similar to the current Lightning Address spec, but without some of its drawbacks.

A key difference is that "Bolt12 Addresses" could rely on DNS record exclusively, whereas Lightning Addresses also need a web server to operate. This helps protect sender privacy (they don't have to reveal their IP to a web server that would then know both the sender and the receiver) and makes it easier to self-host from the receiver perspective (a web server isn't required anymore, the receiver only needs domain for which they can add TXT DNS records, which is very common). The reason "Bolt12 Addresses" could avoid using HTTP is that the sender could fetch the receiver's offer or a blinded path to their node directly from the DNS record, and then use onion messages sent across the Lightning Network to eventually fetch an invoice they can pay. Since we didn't have onion messages prior to Bolt12, the Lightning Address protocol logically had to use another means of communication to let the sender fetch an invoice from the receiver, which ended up being a bunch of HTTP requests sent by the sender to a server, which would then query the recipient's node for an invoice.

Where Bastien's proposal also hits the nail is that it would allow individuals to easily setup their own Address on their own domain (as well as addresses for a few friends or family) using option 3, while services could still offer Addresses to their user at scale by using option 1. Senders wallets would not need to know which option is served by the recipient, and instead first try option 3 and fallback to option 1 if it doesn't work.

However, as Bastien notes, this new proposal doesn't fully address some points, namely:

• it still depends on the DNS infrastructure, but that's a requirement we'll have a hard time to avoid if we explicitly want an identifier that looks like user@domain-name ;
• in the case where a service "hosts" addresses for its self-custodial users (e.g. in a LSP - mobile wallet kind of relationship), the sender still can't verify that the LSP sends back on offer that pays the recipient's node, and not some other node (for example, their own). However, that could be mitigated off-band by adding a verification phase (for example, the recipient displays a hash of their node id alongside their Address, and the sender can check that the hash of the node id they get in the offer matches the one provided by the recipient).

On a different note, Rusty Russel also shared a draft of a "Bolt12 Address" scheme, but this time still using HTTP and much closer to the initial Lightning Address protocol.

The Ads That Matter

I opened this issue of the Latest Strikes newsletter with the new "spammy" "ads-on-Lightning" topic, so it only makes sense to close it with another kind of Lightning Ads, but of a much more interesting ilk. You guessed it, we're going to talk about Liquidity Ads!

As a reminder, Liquidity Ads are a way through which Lightning nodes can advertize to the network that they are looking for a new channel and willing to commit money to its funding. It's basically Tinder for Lightning nodes, processed natively on Lightning's gossip network (instead of using external marketplaces), and where the first date can lead to a nice new dual-funded channel if everything goes well.

We'll probably have the occasion to discuss Liquidity Ads again next week, since there has been some discussions on the mailing list this week. For now, I just wanted to touch on Bastien's proposal to add the option to have Liquidity-Ads-like negotiation between channel partners around a pending (i.e. unconfirmed) channel opening/remodeling. This would be especially useful when linked with splicing, as it would allow channel partners to cancel an on-going splice-out and instead agree on a splice-in where extra funds are added by willing parties (or the other way around).

Closing Bit

Quand les pêcheurs s'aperçurent
Que leurs filets étaient percés
Laissant passer certains poissons
Qui ne seraient pas à la maille
De Bruxelles ou Washington
Ils prirent chacun leur baluchon
Et changèrent de retier.