Towards A K-of-N Lightning Network Node

The recent discussion initiated by a tweet regarding the use of multiple shachains in blockchain technology delves into the strategies for enhancing security through revocation keys. The proposition involves setting a rule that requires a specific number, S, of shachains, all of which must be known to the remote punishing side. This ensures that if any misbehavior occurs, the remote side can issue a punishment effectively. The key aspect here is the configuration that each of these S shachains must be known by at least 'n - k + 1' signers. This setup is crucial because it guarantees that even if 'n - k' signers are unavailable, there remains at least one signer who knows the shachain root and can hence issue the revocation key.

To determine the appropriate number of shachains required, a formula based on permutations where 'S' equals n! / ((n - k + 1)! * (k - 1)!) is used. For instance, with parameters like k=3.4 and n=5, the result is 10 shachains. This computation aligns with policies such as 3-of-5, indicating that ten shachains would suffice under this policy. Such configurations are mapped out specifically, enumerating which signers know the root of each shachain, ensuring redundancy and security in the event some signers are compromised.

Furthermore, the practical implementation of these shachains can be integrated into existing cryptographic frameworks like FROST, where during the setup phase, participants can simultaneously establish the necessary shachains. The on-chain mechanism for these operations involves using MuSig2 for combining public keys of the shachain secrets, simplifying the process to requiring only a single public key revelation and corresponding signature.

In terms of data management, while the full 64-lines shachain construction demands significant storage space (approximately 2616 bytes per revocation), strategic approaches such as truncating state numbering at certain thresholds could potentially reduce the data requirements substantially—by approximately 20%. This optimization acknowledges practical limits in channel continuance, proposing an internal policy to close channels proactively before reaching excessively high state numbers, thus managing the load and storage more efficiently.