Towards A K-of-N Lightning Network Node

Posted by ZmnSCPxj

Sep 15, 2026/16:37 UTC

The primary challenge in managing cryptographic operations within Lightning Network nodes, particularly those configured for k-of-n operations, is not the signing process but the revocation of previous states. While signing is straightforward, facilitated by linear operations in Schnorr signatures and Taproot, revocation requires a more complex sequence involving SHA256 operations to manage up to 2^48 revocation keys efficiently. This complexity arises from the non-linear nature of SHA256, contrasting with the homomorphic properties of SECP256K1 ECC used in signatures.

Several strategies have been proposed to address the challenges associated with k-of-n node configurations, each with distinct trade-offs. One approach involves decoupling channel keys from node keys, allowing multiple signers with different keys to manage channel operations without altering existing BOLT specifications. This method improves resilience against key theft by distributing risk but increases the likelihood of partial channel theft if one signer's keys are compromised.

Alternatively, modifications to the BOLT specification could either remove or multiply SHACHAIN elements, facilitating easier management of revocation keys but requiring changes that affect storage requirements and counterparty operations. Specifically, removing SHACHAIN would simplify key management at the cost of significantly increasing data storage needs for channel state history. Multiplying SHACHAIN, on the other hand, limits the number of viable signers but offers a manageable increase in data overhead.

Another solution involves using multiparty computation (MPC) to handle SHACHAIN calculations, which, while technically feasible, demands substantial computational resources and may not scale effectively in scenarios with high transaction volumes or numerous concurrent channel states due to CPU limitations.

The most radical proposal, which aligns with the intentions of the original developers of key Lightning protocols like Decker-Russell-Osuntokun (also known as eltoo), suggests a consensus change in the Bitcoin blockchain. This change would integrate the processes of signing and revocation into a single atomic operation, significantly simplifying both procedures. However, this requires overcoming the substantial hurdle of modifying Bitcoin's ossified protocol layers, presenting a significant barrier to implementation.

Each option presents a balance between operational complexity, resource demands, and security risk, necessitating careful consideration by node operators based on their specific needs and capabilities. The ongoing evolution of these technologies reflects a broader effort to enhance the scalability, efficiency, and robustness of decentralized financial systems.

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