Latest Strikes 60 - October 23rd-29th 2023

Hey there, Lightninger! As we march toward the Day of the Dead and the Celebration of the Whitepaper, let's take a moment to celebrate how well alive Lightning is, in spite of its obituary having been pronounced by many in the last two weeks in the wake of the replacement cycling attack announcement. A chance for the Lightning world to prove its resilience, since last week got us some exciting achievements: a decentralized Patreon, a new implementation, the LDK going all-in on Bolt12 ... Let's see what it's all about, shall we?

Ecosystem

OpenSats Grants LTS Grant To Matt Morehouse

OpenSats extended a Long Term Support (LTS) developer grant to Matt Morehouse, supporting his work on Lightning security and resilience. Matt is focused on the detection and prevention of bugs and vulnerabilities in Lightning, both at the specification and the implementation level. For example, we owe him the discovery and responsible disclosure of the "fake channel" DoS attack vector, which we covered back in August.

UMA

Lightspark sparked (yep, that's intended) some controversy last week when they unveiled a novel protocol built on top of LNURL-Pay and Lightning Addresses. UMA (Universal Money Addresses) is basically a superset of Lightning Addresses with some added compliance features. When you try to pay a Lightning Address, what happens is your wallet queries some server for some basic pieces of information, such as the minimum and maximum amounts that can be sent, or some metadata such as a profile picture. Once the server responds, the wallet can show you an input page, where you enter the amount you want to send (which must be inside the boundaries the wallet learnt from the first call to the server) and an optional message. When you hit the "send" button, your wallet will then send another query to the server, asking for an invoice for the amount you specified. The server responds, and the wallet automatically pays the invoice if it matches the amount, without any additional interaction from you, the user.

UMA does just that, but with additional exchanges of information between the wallet and the server, such as whether each end of payment is subject to the travel rule, or KYC information about either the sender or the receiver, up to a list of public keys or UTXOs to be fed into on-chain analysis software provided by a third party. UMA is hence typically intended for use between service providers, where a company offers "Lightning accounts" to its end customers. Think Strike, Bitnob, Pouch, Xapo, etc., a number of which announced the integration of the UMA protocol.

While we all get that compliance is important in the world of corporations, baking it right inside the protocol seems perilous. One could argue that UMA is just a superset of Lightning Addresses, fully compatible with the larger ecosystem while giving companies the optionality to carry out their compliance obligations in a more seamless manner. However, this interoperability is precisely what can constitute a threat: it is well established that when companies integrate an open protocol, they often tend to become a dominant actor of the protocol (for example, in terms of number of users of volume of activity) and reach a position where their vision (and hence, implementation) of the protocol becomes the de facto standard, sometimes on purpose. And while it is hard to precisely estimate Lightspark's penetration in the existing galaxy of companies operating on Lightning, what's clear from their pricing scheme is that they aim for high volume, big user base companies. So while Lightspark's intentions are certainly laudable, the reality is there is a clear path in which UMA becomes the way most of the people come to use Lightning Addresses (or even Lightning in general), with all the consequences it carries in terms of protocol capture by corporations and states.

Decentralized Patreon On Lightning Is Here

Last week got us a decentralized alternative to Patreon, based off Lightning and Nostr!

If you're a frequent reader of this newsletter, you probably already know that a protocol called Nostr Wallet Connect (NWC) already enables recurring payments - i.e. the likes of Patreon subscriptions. So what's new?

What's new is the Mutiny team extended a tool and service called Zapple Pay (which we covered here back in July), which initial goal was to help iOS users escape Apple's censorship on Zaps. You could then connect you Lightning wallet to Zapple Pay through NWC, paste your Nostr public key (a.k.a npub), and from then on the Zapple Pay service would watch your Nostr notes and, any time you responded to a note with a specific emoji, trigger a notification to your Lightning wallet over NWC, telling to zap the note you were responding too.

Now, what if instead of being triggered by the user commenting a certain emoji below a note, Zapple Pay could ask your wallet to zap a certain Nostr profile automatically every set period of time (for example, every day). Technically speaking, that's not very different from the above: zapping a user is equivalent to zapping a note, since every thing in nostr is just notes. Triggering the zapping request based on a clock rather than a comment is even easier to implement. And, just like that, Lightning-based Patreon-like subscriptions are here.

What's also brilliant is it makes use of existing "infrastructure": if someone already has a Nostr account with a Lightning Address referenced in their profile, then you can "subscribe" to them and send them a few sats on a daily, weekly or monthly basis, simply by visiting zapplepay.com/autozap/<their_npub> and setting up a NWC link using compatible wallets such as Mutiny or Alby. My "page" is here for example, and the root of the autozap section lets you explore some popular users.

Interestingly, the same week, Pablo released the latest version of highlighter, a Nostr client specifically tailored for fruitful reading on the internet. Initially called Zapworthy, the project has greatly evolved since, becoming a feature-rich reader. This new version brings some interesting Lightning-related new features, such as Zap-splits (when you zap an highlight, which is a Nostr note quoting the original content, your zap automatically gets split between all the persons that were involved in you seeing that content - i.e. the original content producer, the highlighter, etc.) ; the use of Data Vending Machines (i.e. autonomous AI agents paid in sats for their service) to automatically transcribe non-textual content such as podcasts into text, so that they can be highlighted ; and Patreon-like subscriptions.

Highlighter's subscription mechanism seems a bit different from that of Zapple Pay, and I'm actually not sure yet as to exactly how it works. My personal experience when testing it out was that it didn't seem to use NWC, but rather a new kind of Nostr event (namely kind 7001), which my guess is the Highlighter website uses to keep track of which user you have a paying subscription too, and automatically ask your wallet to renew the payment every month.

Wallets & Tools

More e-cash x Lightning Synergies

We've already touched in this newsletter on the role Lightning plays as a common transaction medium interconnecting other kinds of systems and protocols built on top of Bitcoin. One example of it is how different e-cash mints (servers that issue custodial, privacy-preserving IOUs against bitcoin deposits to their users, which can later be redeemed against bitcoin when leaving the mint) can become interoperable and let their users seamlessly transaction with each other by using Lightning as a common gateway.

It its latest release, Minibits focused on this interoperability with other mints (and Lightning in general) with the ability to zap Nostr users to their Lightning Address using your e-cash tokens. It works just as making any other Lightning payment with e-cash: you send your tokens to a Lightning gateway located in the same mint as you, and this gateway then proceeds to send the payment on the Lightning rails. More generally, this release brings the whole LNURL toolkit to the wallet, with LNURL-Pay support for quick deposits when you run out of money in your wallet, and LNURL-Withdraw for quickly getting your funds out of the mint and back into Lightning. Sweet!

Spec & Implems

LDK Goes Full Bolt12

Last week the Lightning Dev Kit (LDK) Lightning implementation in Rust went full Bolt12 and released alpha support for both Bolt12 sending and receiving. As a reminder, Bolt12 is new piece of the Lightning protocol, still in development, which notably allows paying to static codes instead of having to manually ask for an invoice, and does so in a Lightning-native way, where LNURL relies on web servers and DNS.

On top of that, this release also brought a new denomination for on-chain fees, which I found quite interesting. Instead of the traditional "low", "medium" and "high" feerates which are the norm in most wallets, LDK users can now select the fee based on what the Lightning node is trying to do. For example, the OnChainSweep parameter is equivalent to a high priority, as sweeping the funds from a channel close transaction requires to be achieved in a timely manner ; whereas the AnchorChannelFee is equivalent to a minimal fee, since the transaction can always be fee-bumped later using anchor outputs should the need arise.

Speaking of Lightning implementations written in Rust, Vincenzo Palazzo announced a new one! Called Lampo, this new implementation will feature the ability to easily change the node's API (e.g. how you issue commands to the Lightning node) or on-chain data source (do you connect your Lightning node to your Bitcoin node, or to an Electrum-like server, etc.), and will support Fedimint (federated e-cash), LSP (Lightning Service Providers), and VLS for secure signing. It also seems to be taking a more bottom-up and community-driven approach, with the goal to be an alternative to more business-centric implementations. Can't wait to see the first release!

Trivia Of The Week

As a routing node, is it possible to limit the size of payments that go through my channels?

Closing Bit

L'écrit concis est tombé
Point final, ultime enveloppe
Portant les milliers de lettres potentes
Qui ont fait basculer le monde.