[c-lightning] Policy signer PoC

[Devrandom]

Agreed on all points.  Would you agree that there is no risk that
composable musig (or musig composed with threshold sig) is impossible for
some reason?  i.e. we are just searching for the most convenient protocol
and we have some candidates?

On Fri, Dec 13, 2019 at 11:31 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/c-lightning/attachments/20191215/57d198be/attachment.htm>