Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week got us a huge Zeus wallet release, a Core Lightning plugin for SuperScalar, and an interesting path towards N-of-K Lightning nodes.

Zeus Release

The Zeus team seems to have been cooking with the latest version of the Zeus wallet (v13), currently in alpha¹. This new release brings a number of significant improvements, as well as a new “node in the phone”.

Zeus v0.13 comes with the possibility to run LDK as an embedded node, on top of the current LND option. The LDK node supports Bolt12 Offers as well as Bolt11 invoices, and keysend. It also supports requesting channels from an LSP, as well as renewing the lease on those channels². On the privacy and customization front, the LDK embedded node lets users specify their own Esplora, Versioned Storage and Rapid Gossip Sync servers.

Portability

v13 also introduces the ability to transfer channels across devices, whether it be to a new phone or to a server. My understanding is that this should work for both LND and LDK, with different mechanisms:

• the LND database is backed up, either locally or to Zeus servers (I assume encrypted), and can be used to migrate to a full external LND node without having to close channels ;
• since the LDK node uses VSS, it should be able to handle multi-device access, letting users easily switch devices while still using the same node.

These 2 portability mechanisms are hence not exactly the same feature-wise: LND’s portability is more of an “eject and use elsewhere” feature, while the LDK node should allow for more back and forth between devices.

Performance

In the same post, Kaloudis also highlighted a performance improvement for embedded LND thanks to a new database. On top of all that, he also announced that the new LDK embedded node significantly improves application start-up time, with a reported 67% improvement (over the embedded LND node, I assume). Pretty neat, especially since it has historically been one of the major paint points in Zeus.

StackerNews Discussion

Superscalar CLN

Remember SuperScalar? There is now a Core Lightning SuperScalar plugin being actively developed by 8144225309, who also wrote the implementation we covered a few weeks ago.

Towards a K-of-N Lightning Network Node

Our favorite hashling ZmnSCPxj posted on Delving Bitcoin about a path towards a K-of-N Lightning Network node and, crucially, a network of such K-of-N Lightning nodes.

By ZmnSCPxj’s definition, a K-of-N Lightning node is a node where the operators possesses a total of N devices, and where:

• the funds on the node remain in their sole control as long as less than K devices are compromised, and
• the funds on the node remain retrievable by the operator as long as at least K devices are usable.

This is basically the idea of a K-of-N on-chain multisig, but the additional complexity inherent to the Lightning Network protocol makes such a design harder to achieve in the Lightning context.

The Scheme Available Today

A pseudo K-of-N Lightning node scheme available today would be to use a set of independent signers, all connected to the same node, but each responsible for holding the cryptographic material of one specific channel of the node. Indeed, the specification doesn’t require any specific derivation scheme from a “root key”, either to derive per-channel keys or for the public identity of the node. While the general direction pursued by implementations to this day has been to anchor at least the per-channel keys to a root key (which is very convenient for backups), nothing prohibits the use of completely distinct keys for each channel.

With such a setup, where each channel gets its own independent key, and where each of those keys is stored on a separate device, it’s possible to mitigate the risks. The compromise of one device can only lead to the loss of funds in the corresponding channel. Other channels are untouched³. This is similar to using multiple nodes, except here we get the topology and reputation advantages of having only one big node. ZmnSCPxj released an implementation of such a system for LDK a few months ago.

This scheme, while interesting, is not a K-of-N node: the compromise of one device still means the stealing of some funds. Conversely, the loss of one device could lead to loss of the funds (that is, without any backup). The risks are spread, but we don’t have the threshold effect we seek.

Towards an Actual K-of-N Node

Using Nested Musig2 and Taproot channels, it seems possible to build a Lightning node with one root key that is the Musig2 aggregation of multiple keys, each managed by a distinct device. This root key would then be used to derive channel keys for Taproot channels, as is currently done my most implementations. However, ZmnSCPxj argues that one specific element of the specification currently hinder the development of such a K-of-N node: the derivation of revocation secrets.

Revocation Secrets And Their Derivation

Whenever the state of a Lightning channel changes, the commitment transaction underlying the channel state needs to change as well. For example, every time a payment is routed through a channel, it requires 2 channel (and hence commitment transactions) updates: one to add the HTLC output, and then one to remove it. For each transition :

1. One peer (peer A) generate signatures for the new commitment transactions and sends the signature to the other peer (peer B). The new state therefore becomes enforceable by peer B (who can also still encore the previous state).
2. The remote peer responds with their revocation secret for the previous state, meaning they shouldn’t try to enforce it anymore, since it would result in peer A publishing the justice (penalty) transaction, using the revocation key to claim the total capacity of the channel.

The ability for peer A to punish bad behavior from peer B (and vice-versa) is conditioned to them storing the revocation secrets of all past channel states. Each time a payment is attempted, that’s 2 additional 32 bytes secrets to store⁴. In other words, revocation secrets storage requirements grow linearly with a node’s traffic. To turn this linear cost into a constant cost, Lightning Network developers have put in place a clever trick: instead of each revocation secret being independent, they are derived from a root 256-bit secret seed using a deterministic algorithm that only depends on the seed and the index of the secret (e.g. whether it is the first, second, or Nth update of the channel). The counterparty can then only store a limited set of secrets at a time and derive other secrets knowing only their index (and, crucially, without knowledge of the seed).

While this trick is amazing for storage efficiency, it has one little downside that affects our K-of-N design: if we derive the commitment secret from a common root, and an attacker stealing this root means they are able to steal funds (since they can know future revocation secrets in advance), then we lose our threshold requirement, even if we were to use one root per channel.

The Fix

ZmnSCPxj proposes to fix this simply by dropping the secret derivation, and instead storing each revocation secret independently. This would “triple the effective on-disk size of channels with long history”, since we’d go from only storing the HTLC hash data (~32 bytes) to also storing two 32-bytes revocation secrets, on top of the hash data.

When it comes to modifying the specification, ZmnSCPxj details how they’d use the “it’s ok to be odd” rule⁵ to gradually migrate the network, from its current state to a network of K-of-N nodes. Nodes that signal with the odd bit would still return derived revocation secrets to their peer (and hence still be compatible with “legacy” nodes), but would not expect derived revocation secrets from their peers. Nodes signalling with the even bit would go a step further and not provide derived revocation secrets to their peers. They could hence not establish channels with “legacy” nodes, but could do so with nodes signalling on the odd bit, which would therefore act as gateways until (maybe, eventually?) the network adopts the K-of-N nodes mechanism at large.

---

That’s it for last week. Thank you so much for reading this far! As always, feel free to drop any feedback, it’s much appreciated. See you next week!

Footnotes

1. Actually, it’s now in beta. ↩

2. Implementing the LSP1 and (draft) LSP7 from the LSP specification. ↩

3. Apart from things like reputation risk, and such. ↩

4. One for adding the HTLC, and one for removing it. It doesn’t matter whether the payment was successful since, in both cases, addition and removal of the HTLC are performed. ↩

5. Lightning nodes signal feature support (either to their peer or the whole network) by setting feature bits (you can think of them as flags). To easily distinguish between optional and compulsory features (i.e., do I require that my peer support feature X in order to open a channel with them), a protocol rule is that optional features are signaled using odd bits, while compulsory features use even bits. See the specification for more details. ↩