Welcome to a weekly summary of noteworthy news and developments in the Lightning Network ecosystem. If you've followed my prior work, you might be familiar with the previous instance of the Latest Strikes newsletter, which ran (roughly) from September 2022 to February 2024¹. What you're currently reading is a modest attempt at relaunching this thing, with no strings attached.

And now, without further ado, let's dive right in!

Last week, moneydevkit (MDK) launched their public beta. The MDK's goal is to allow developers to integrate self-custodial Lightning payments into their app with just a few lines of code.

One way to sum it up is that it's basically phoenixd but without having to run phoenixd on a server alongside your actual app (say, a store or a blog). Instead, your LN node runs on-demand inside your app, on the backend. For now, only the Nextjs framework is supported.

Like in similar Lightning Service Provider (LSP) setups, your node is connected to one of MDK's always-on nodes, which provides inbound liquidity and abstracts away channel management. When someone tries to pay you, your MDK node will create an invoice, specifying its private Lightning channel with MDK as a routing hint. When the payment reaches MDK's infrastructure, they ping your node to let it know it can claim the incoming HTLC. Since the invoice was crafted by your node, which keys are only on your infrastructure (the one where you deployed you app), MDK can't steal the payment from you since they don't know the preimage.

Received payments stack up on your side of the channel. You can then decide to transfer them to another node (via LN Address or Bolt12) from your MDK account, on MDK's website. The MDK infrastructure then issues a request to your MDK node, which only pays if the LN Address/Bolt12 matches one that you provided during the initial config². This ensures this setup is actually self-custodial, since payments can only be sent to whitelisted destinations. In case anything goes wrong you can also, of course, recover on-chain with the seed phrase and some (yet unreleased?) recovery tool that lets you force close the channel.

A great thing about the MDK Nextjs package is that it is meant to run in serverless environments, thus making it fairly easy to deploy Lightning-enabled apps. For example, it took me around half an hour to build this (quite rudimentary) tipping page, built with the MDK and deployed on Vercel. Bear in mind MDK this is still in beta, but it's definitely promising!

Jonathan Harvey-Buschel shared his work on Gossip Observer, a tool for collecting and analyzing Lightning gossip traffic.

Gossip messages are chunks of data exchanged by Lightning nodes, in which they communicate to each other the existence of new nodes or new channels, as well as node updates (e.g. alias change) or channel updates (e.g. fees change). It takes its name from the way this data is propagated across the network in a gossip/flooding protocol where each peers communicates new data it learned (either by changing something themselves, or by receiving an update from a peer) to all of their peer³.

The preliminary findings of a short 24 hours data collection are that the time for a gossip message to propagate to 75% of the network has dropped from ~500 seconds in 2022 (obtained with similar measurements) to ~200 seconds today. Also, it appears some nodes are (probably not intentionally) "spamming" the network with unnecessary messages, such as node announcements repeated more than 144 times in the span of 24 hours, while we expect such messages to only be send a few times in the lifetime of a node⁴.

In a following comment, Jonathan also opened a discussion on the opportunity to adopt a design similar to that of Erlay (intended to be used for transaction propagation on Bitcoin) for broadcasting gossip messages, where Lightning nodes would first determine what messages an other node is missing, and then only send them those messages instead of broadcasting all messages. However, the approach would have to be adapted to the nature of Lightning gossip, with 3 different kinds of messages and relaxed privacy considerations.

The Validating Lightning Signer (VLS) team published an interesting blog post about the Lightning custody spectrum. They define 4 levels of custodianship: custodial, shared custody, self-custody and self-custody with validation. The main difference between the last two lies in whether the node's logic is all in the same place, or split between the validating signer on the user's device and the rest of the node's features on a remote server. The shared custody, on the other hand, is characterized in VLS' taxonomy by the fact that the signer on the user's device does not validate what is presented to them by the server before signing.

Typically, the MDK package we mentioned earlier in this issue seems to fall into the "self-custody with validation" category, since the embedded node initiates receiving payments, and only accepts to send payments to whitelisted destinations.

Thank you for reaching the end of this issue! I truly hope it provided you as much value as I enjoyed writing it. I want to take this first issue of the Latest Strikes newsletter reenactment as an opportunity to share what I intend to do with this thing, and what pitfalls I intend to avoid, learning from past experiences.

The goal is simple: a concise, technical weekly summary of new developments and discussions in the Lightning Network world. To ensure this works, I've set a few rules to myself:

That's basically it. Thanks again for reading this far, and feel free to reach out on nostr for comments! Zappy week!