Towards A K-of-N Lightning Network Node

The recent publication of the Nested MuSig2 Paper has sparked significant interest in integrating multisig functionality with Lightning Network nodes using Taproot channels. This integration aims to enable k-of-n multisig configurations, where a specified number of signatories out of a total are required to authenticate transactions and changes, enhancing security and flexibility. The adoption of Nested MuSig2 could allow for seamless multisig operations within the Lightning Network, assuming modifications to the existing BOLT protocol.

Significant challenges arise from implementing k-of-n multisig wallets in the Lightning Network due to its unique channel and transaction dynamics. Currently, the network doesn't support direct expression of k-of-n requirements, unlike onchain transactions. Therefore, users desiring this functionality must either wait for broad adoption of these new protocols or rely on gateway nodes that implement early modifications, potentially compromising privacy and efficiency.

A key consideration is the management of channel counterparties. Ideally, a node operator would want to keep options open for anyone to establish channels to maximize routing opportunities and fee generation. However, this openness increases the risk of fraudulent activities if channel counterparties are not well-vetted, which is a substantial security concern for node operators with significant funds.

Another aspect involves the practical implementation of multisig arrangements beyond the simple use of secure elements or trusted execution environments. Typically, secure setups promise protection against unauthorized access, but vulnerabilities remain through manufacturer backdoors or debugging interfaces that could expose private keys. Thus, reliance solely on hardware-based security might be less effective than a robust multisig setup, where multiple independent validations are required to access funds, significantly increasing security.

The current system uses a revocation mechanism essential for updating channel states securely. Each state transition involves generating a new revocation key, complicating the implementation of k-of-n multisig setups. The revocation process relies on shachain, a chain of hashes that cannot accommodate k-of-n requirements due to its cryptographic nature. This limitation necessitates a proposal to modify the BOLT specifications to remove shachain dependencies, replacing them with a structure that supports multisig configurations more feasibly.

Proposed changes to the BOLT protocol include introducing new feature bits that allow nodes to identify compatibility with non-shachain nodes, facilitating smoother transitions and interactions between various node configurations in the network. These modifications aim to support the diverse needs of network participants while ensuring the security and functionality of the Lightning Network as it evolves to incorporate more complex multisignature schemes.