[c-lightning] Policy signer PoC

[ZmnSCPxj]

Good morning devrandom,

I note that the medium article mentions the use of multiple signers (multiple secure elements) for a single Lightning node, and mentions the use of techniques as 2p-ECDSA, mp-ECDSA, and MuSig.

There is the possibility that we will end up using MuSig for channels, with a MuSig of both participants in the channel.
In combination with the upcoming bip-schnorr (and possibly bip-taproot), such a MuSig-between-both-participants would give privacy advantage: even if the channel is published, it moves the effort to remember the historic existence of a published channel that has now been closed to those who are surveilling the network, instead of simply asking any archive fullnode for explicit 2-of-2 (because ordinary non-Lightning users will either use 1-of-1 for convenience, or *at least* 2-of-3 to protect against loss of one signer; n-of-n where n > 1 is most likely an offchain mechanism of some point (trustless offchain requires veto rights for each participant, which is implementable most easily by requiring permission from each participant, hence n-of-n for n participants), and the top offchain system is Lightning).

If we wish to use MuSig inside a single node, and *also* MuSig between both nodes of a channel, this is precisely the "composable MuSig" problem I brought up before on bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017493.html

The proposal I make in that post is to allow each participant in the topmost MuSig to provide more than one `R` hash commitment and later `R` revelation.
Of course, practical protocols would require some cap or limit on the number of `R`s one node of the channel can provide, thus creating a hard cap on the number of signers/hardware securit modules that a node can have.

Additionally, MuSig is an n-of-n system, and by my understanding (though you should really ask andytoshi or sipa) a different "publicly verifiable secret sharing" should be used to implement k-of-n, at least if each hardware security module is allowed to select its own private key (which it probably should: you may want to source HSMs from multiple manufacturers in case one or a few manufacturers turns out to be non-tr\*stworthy, so each hardware security module should ideally be designed to assume dishonesty from other hardware security modules).
For the hardware security module case, it seems to me that k-of-n is what you would prefer, though I suppose it would not require a publicly verifiable secret sharing if the single true owner is the one that computes the shares using *temporary*, will-be-burned-after-use, hardware.
I believe the public verifiable secret sharing is still being worked on, thus any specific issues that may arise are not even considered yet; but it seems to me as well that making it composable with MuSig at the channel UTXO would be compatible with multi-`R` proposal.

Of course, after further thought, it may be possible to create a k-of-n with a trusted setup  executed by a single "true owner" of the funds, without requiring verifiable secret sharing, and then confirm that each hardware security module knows only one share and remembers it across power cycles, and that may still work well even if some subset less than k of hardware modules are compromised.

Regards,
ZmnSCPxj