About a week ago, I posted about this paper describing a nested multisig threshold scheme for a lightning node. #1552628

@k00b asked what such a thing would be useful for and I did not have a terribly good answer.

Today, I saw a blog post by one of the paper's author's in which he undertakes to explain a little of what he thinks it might be useful for.

In the Lightning Network, node operators are required to keep their private key online and ready to sign, but this means they have a single point of failure and a single vulnerability that holds all of their channel funds. It would be preferable for large channel operators to be able to have some offline backup keys as well as to be able to tolerate the corruption of some bounded number of online keys as is standard with threshold key management. This is what nested threshold signatures provide: One participant in a BIP 327 MuSig-based contract can use a nested threshold signature protocol to construct a single aggregate MuSig participant key for themselves that actually consists of many secrets. Furthermore, some of these secrets can be air-gapped and offline cold storage secrets and some subset of secrets may be corrupted without losing channel funds.

Does this answer the question? I don't know. Is it a valuable thing to have a lightning node where you must keep a minimum threshold of keys online, but can tolerate the corruption or compromise of some number fewer than that threshold?

The blog post also goes into some of the math and the signing time for this particular scheme. While it is still quite dense, I found the blog post a little more accessible than the formal paper.