Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week caught my eyes with a refreshing VPS-first Lightning node project, an interesting discussion around Onion Message jamming, and Eltoo channels on signet.

I want to preface this edition with a quick question on StackerNews etiquette. Latest Strikes now has its own website, so do you stackerzz still prefer having the full text here, or just a link to the website? Thanks

Virtual Private NodeVirtual Private Node

The v0.4.0 of the Virtual Private Node^[1] now ships with LND by default, and a very nice TUI to manage the node. The goal of the project is to provide a one-command installer to let users go from nodeless to node runners in minutes.

This project is quite refreshing and looks pretty gorgeous, so we'll probably follow it closely in future issues. Nice work @ripsline.

StackerNews Discussion

Onion Message JammingOnion Message Jamming

A very interesting discussion around Onion Message jamming in the Lightning Network took place on Delving Bitcoin last week. It started with a very clear summary of the issue and proposed solutions by Erick Cestari from Lightning Labs.

Onion Messages (OM) are messages transferred across the network of Lightning nodes using onion routing, akin to how payments are routed across the LN (or how packets travel in the TOR network). One of their primary use cases today is for Bolt12 Offers, where onion messages are used to send invoice requests and invoices themselves across the network in a privacy-preserving manner. An issue is that, much like channel jamming, onion messages can be abused to spam nodes, although the exact nature of the ressource being wasted differs^[2]. To prevent spam, all Lightning implementations supporting Onion Messages^[3] also ship a rate-limiting mechanism. However, when an attacker engages in a wide spam attack across the network, these rate-limiting mechanisms are triggered at large, disrupting the propagation of onion messages. This is onion message jamming.

The explored solutions are:

• tying onion message forwarding to the payment of an upfront fee, either per message, batched or with a session system ;
• limiting the number of hops (either with a hard limit, or by requesting a PoW which difficulties grows with the number of hops) and tying a node's "onion messaging allowance" to its public capacity ;
• propagating backward a "message dropped" signal when rate limits are reached, instead of silently dropping messages.

Here is a short, non-exhaustive pros and cons table:

This is only a condensed summary of the discussion, and I encourage the reader to delve into Erick Cestari's recap, as well as the resulting discussion. What seem to emerge is that:

• with LND's implementation of Onion Messages coming, now would be a good time to implement at least a minimal OM jamming mitigation mechanism,
• the backward propagation mechanism is the simplest, and could act as a first stepping stone,
• upfront fee-mechanisms are more potent, but also more complex.

Eltoo State Channels On SignetEltoo State Channels On Signet

Aaron Zhang demonstrated an Eltoo channel state chain on the Inquisition signet, going from opening the state channel, to updating its state a few times and settling it on-chain. It uses SIGHASH_ANYPREVOUT (APO) for the state transitions, and settles using CTV.

That's it for last week! Once again, thanks a lot for reading this far, and until next week!

1. That's a pun on VPS, on which this software is design to run, although it can of course run on any machine. ↩

2. In channel jamming, the ressource is liquidity. In onion messages, the spam is more akin to the traditional issues linked to wasting ressources and DoS attacks. ↩

3. Which is all of them, with LND still working on its implementation. ↩

4. Note that it is already partially the case, since most rate-limiting rules give higher limits to peers with a shared channel. But the upfront fees turns this soft coupling into a hard coupling. ↩

5. The reactive nature of this mechanism, meaning it only starts after the network begins to be disrupted, can be seen as a drawback. However, it also means that under nominal conditions nothing gets in the way of the flow of onion messages. ↩