Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week saw the merging of both the Simple Taproot Channels and the zero-fee commitments channel types into the specification. There was also an interesting post around post-quantum Lightning, and a Boltz Backend update.

Post-Quantum Lightning

Olaoluwa “roasbeef” Osuntokun published an interesting summary of the different options available should Lightning migrate to post-quantum cryptography (PQC). He identifies the different cryptographic schemes available, and the respective sizes of both their public keys and the signatures they produce.

A constant across signature schemes is that they are at least one order of magnitude bigger, with up to a 75x increase of the size for the SLH-DSA-128s algorithm. Some variants try to reduce this size (typically halve it), but they have the big downside that the number of signatures they can securely produce is limited to around 16.8 million (2^24). This might seem like a lot in isolation, but Lightning nodes frequently sign messages for gossip (e.g. channel announcements and updates), invoices and onion-routed packets. In practice, for a node with 1,000 channels, the cap on the number of signatures would be reached in 4 months. Such variants hence don’t seem very practical for Lightning.

Another consideration is that the current cryptography in Lightning sometimes allows for nice optimizations that would be lost with the switch to PQC:

• at the gossip layer, we use the same key to both establish the communication channel (using Diffie-Hellman) and sign our gossip announcements ;
• a nice trick that allows us to only use one single key for the whole onion packet and have each hop tweak it for the next layer of the onion is lost. Now, each layer of the onion requires its own key, which means we go from constant-size onions to linear growth with the number of hops. And that’s on top of the already increased size of keys and signatures.

The research also touches on the option of doing hybrid cryptography, meaning we’d combine both legacy and post-quantum cryptographies so that if either one fails, the secrets are still safe. The gist of it is that PQ sizes are so big compared to those of classical cryptography that going with the hybrid approach wouldn’t bear a huge cost, and would protect against potential shortcomings of PQC.

StackerNews Discussion

Simple Taproot Channels Merged

The Simple Taproot Channels specification got merged, with interoperability achieved between LND and Eclair. This specification is a first step towards using Taproot in Lightning, and focuses on enabling Taproot in funding and commitment transactions, leveraging MuSig2 to achieve cooperative channel closings that are indistinguishable from regular Bitcoin transactions, as well as reduced on-chain footprint.

This new channel type paves the way for additional Taproot/Schnorr-related enhancements such as PTLCs (though quantum-resistance debates may slow adoption/development?). A crucial still-missing piece is the gossip announcement of simple taproot channels, for which the specification is still at the draft stage, as we briefly touched on previously when covering Nested MuSig2. As a result, Simple Taproot Channels are still unannounced for now.

StackerNews Discussion

Zero-fee Commitments Merged

The new zero-fee commitments (Pay-to-anchor/ephemeral dust) channel type was also merged into the specification last week, following interoperability between at least Eclair and the LDK. This new channel type allows commitment transactions to not pay any fee themselves, and instead rely on a single anchor output that can be spent by anyone to determine the fee-rate of the whole package, using CPFP. This anchor output can even carry no economic value (0 satoshis), as long as it is ephemeral (i.e. spent in the same block where it is created)¹.

This is a very nice upgrade, because it removes the burden of having to agree upon a fee-rate at commitment signing time that may very well be completely irrelevant by the time the commitment transaction is published ; and considerably simplifies the previous anchor outputs design by leveraging the new v3 transaction relay policies.

Boltz Backend Release

Boltz Backend v3.13.0 was released which, among many other things, enables Boltz operators to use multiple nodes in their infrastructure, and brings full Arkade support.

---

That’s it for last week! Thanks a lot for reading this far, and until next week!

Footnotes

1. Note that this anchor output also contains any trimmed outputs (e.g. uneconomical outputs) and rounded millisatoshis. It’s zero-value if and only if there is no trimming nor rounding in a given commitment transaction. ↩