Signing without knowing the signers

[ineiti]

This is a lazy question, as I don't want to dive into the paper ;) Feel free of course to tell me to RTFP...

Is it possible to sign without knowing who of the nodes will be in the threshold of the signers? The application would be to have a threshold signature from a group of nodes (which is known beforehand), but where you don't know which nodes will be available. But you assume that a threshold of them will sign the message.

So in your very nice example (really love the detail, exactly what I need ;), what would happen if the aggregator include_signer for all signers, but then only a threshold of them return a partial signature? Will the aggregator be able to finalize the signature?

[burdges]

I have not yet looked at the code here, but since we came up with roughly the same protocol in https://eprint.iacr.org/2020/1245, as did blockstream guys in https://eprint.iacr.org/2020/1261, and did a security proof for it I can answer:

You do not care about the message or signer set during round one, but all signers must know the message and signer set when finishing in round two.

There is one remaining point of contention over the "flexible rounds" because some of us advocate "hardware defenses" for the pre-witnesses/pre-nonces. You'd implement this in Rust using "session types", meaning not implementing serialization for pre-witnesses/pre-nonce secret, which kills "flexible rounds". This makes the code much safer to use in practice, but contradicts the "fr" advice of the frost authors.

A software developer who writes pre-witnesses/pre-nonces to disk is playing with fire, so an "fr" code base harms your use cases. Yet, a hardware wallet vendor could internally add serialization to pre-generate pre-witnesses/pre-nonces, and thus add the "fr" to a non "fr" codebase, provided they implemented some other style of hardware protection against reuse.

[isislovecruft]

Hi @ineiti! Thanks for the questions.

So in your very nice example (really love the detail, exactly what I need ;), what would happen if the aggregator include_signer for all signers, but then only a threshold of them return a partial signature? Will the aggregator be able to finalize the signature?

If the aggregator calls include_signer(), then that signer must provide a partial signature, otherwise the polynomials for the vector of pre-shared commitments and public keys does not work correctly. That is, the aggregator must only call include_signer if they are 100% certain that that participant will sign. Additonally, the set of expected signers is something each participant needs to know when they are each computing their own partial signature.

If you have any suggestions on making the API for this any better/more intuitive, or ways that I could make the documentation more clear, I'm all ears!