Towards A K-of-N Lightning Network Node

Posted by ZmnSCPxj

Nov 2, 2026/17:46 UTC

A method is proposed for managing multi-signature revocation keys in a distributed environment, drawing upon the concept of grouping signers for enhanced security and operational efficiency. Each group, consisting of N - K + 1 signers, shares a unique key, and their commitment for a particular sequence number n is generated by applying a pseudorandom function (PRF) to the combination of this shared key and a channel-unique constant c concatenated with n. The value c is fixed per channel at the time of channel opening, such as by using the node’s funding public key, and is strictly bound to that specific channel to prevent reuse across different contexts.

The system ensures that any collection of K signers will collectively include at least one member from every signer group, due to the property that K + (N - K + 1) exceeds N. This allows any set of K online signers to compute the required commitment point for a given state. The revocation public key is constructed as a MuSig2 aggregate over the set of points derived from each group’s PRF output multiplied by the elliptic curve generator G: MuSig2([PRF(subkey1, c || n) * G, PRF(subkey2, c || n) * G, ...]). Any of the current K online signers can calculate this public key, provided they receive the requisite points from participating machines.

When it becomes necessary to revoke a state, each signer must individually validate that the new transaction state is legitimate, ensuring that proper signatures are present and that the transition is valid. Only after such validation does a signer agree to release their portion of the secret, specifically the value PRF(subkeyN, c || n). Once K signers have released their values, any one among them can reconstruct the private key underlying the MuSig2 sum and transmit it to the channel counterparty in accordance with the modified BOLT specification.

This approach offers computational advantages, reducing the need for repeated SHA operations on the part of the signers. Instead, the use of PRFs such as tagged SHA or HMAC-SHA simplifies the workflow, though it requires the channel counterparty to maintain additional persistent storage to track these commitments and secrets over time.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiDecoding BitcoinWarnet
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project.

Give Feedback