Towards A K-of-N Lightning Network Node

By enabling k-of-n multisig configurations—where any k signatories out of n are required to authorize transactions—this evolution aims to address longstanding challenges in trust distribution and operational risk. However, incorporating such multisig setups into the Lightning Network is not straightforward due to its unique transaction lifecycle and the current limitations of the BOLT protocol suite, which does not natively support k-of-n arrangements for channel management.

Presently, users seeking robust multisig functionality must either wait for broad ecosystem upgrades or operate through gateway nodes that adopt early protocol modifications. This approach can compromise privacy and efficiency, especially as it relates to managing open channels with a diverse set of counterparties. While broad connectivity maximizes routing opportunities and potential fee income, it inherently exposes node operators to increased risks if channel peers are insufficiently vetted. Effective multisig deployment thus demands not only technological adaptation but also prudent operational policies around counterparty selection.

In terms of implementation, reliance on dedicated hardware security modules or trusted execution environments has been typical for safeguarding private keys. Yet, these methods are vulnerable to manufacturer backdoors or debugging exploits, making them less reliable than a well-architected multisig design. The latter requires multiple independent parties to validate sensitive operations, thereby dramatically improving resilience against single points of failure.

A core technical challenge lies in the Lightning Network’s commitment state revocation process, which currently depends on shachain—a hash chain structure designed for efficient secret management. Shachain’s cryptographic nature does not accommodate k-of-n requirements, creating a significant obstacle for multisig-enabled Lightning nodes. Proposed solutions involve altering the BOLT specification to decouple revocation from shachain, replacing it with mechanisms better suited to multisignature contexts. Such changes would be marked by new feature bits within the protocol to allow seamless identification and interoperability among nodes supporting these enhancements.

Experimental research has explored implementing two-party shachain schemes under adversarial assumptions, as demonstrated in the shachain2pc proof-of-concept. In this model, two parties collaborate to generate shared shachain values using secure multiparty computation (MPC), but with considerable resource demands—each party requires over 700MB of RAM, and state derivation takes over a second per operation. These inefficiencies highlight the need for optimized MPC protocols or alternative architectures, particularly for high-throughput networks like Lightning where scalability and economic viability are paramount.

Security analysis reveals that naïve MPC implementations risk intermediate state manipulation, potentially exposing critical revocation keys. Robust circuit construction across all hash levels is necessary to prevent such attacks. Existing toolkits like emp-ag2pc offer foundational support but lack features for more complex arrangements such as 2-of-3 MPC, which are essential for practical multisig deployments. Workarounds, such as isolating a third signer or adopting alternate secret-sharing schemes, trade off between security, availability, and operational complexity.

The underlying mathematics of multisig revocation management involves distributing shachain commitments across groups of signers, calculated combinatorially based on the desired threshold parameters. Each group's root secret is used to produce per-commitment secrets via pseudorandom functions, leveraging techniques from replicated and pseudorandom secret sharing literature. This structure ensures that any authorized subset of signers can reconstruct necessary secrets, while unauthorized subsets remain unable to compromise key material. To mitigate risks associated with “key cancellation” during signature aggregation, MuSig2 is employed for combining public keys, preventing malicious actors from nullifying others’ contributions.

Transitioning away from shachain-based revocation necessitates protocol-level modifications. Recent work has culminated in the proposal and implementation of a channel_type extension called option_independent_secrets, represented by feature bits 266 and 267. Under this scheme, each side may independently generate and manage its per-commitment secrets, unconstrained by shachain’s linearity. Receivers are tasked with storing every secret they obtain, with practical storage limits and policies for cooperative closure when thresholds are reached. Both lnd and Core Lightning have developed interoperable implementations, confirmed through comprehensive breach and operational testing (independent-secrets-interop). These implementations default to standard behavior unless explicitly enabled and provide mechanisms for safe upgrade paths and database versioning.

The revised protocol introduces rigorous rules for secret generation, storage, and revocation actions among multi-signer nodes. Notably, no group of signers below