Compatibility with ROAST and the missing ShareVal algorithm

[MatthewLM]

I've been assessing the potential use of this library for implementing the ROAST scheme for coordinating signatures.

In the ROAST paper, the ShareVal algorithm is required that can identity an invalid signature share upon receipt without having to wait for the aggregation stage. This frost library only identifies a single invalid signature share during aggregation which is insufficient to implement ROAST.

Therefore it appears that it is only possible to deny a single cheater from entering a ROAST "responsive signer" set when the final signature share is provided. Maybe there can be an adaption to ROAST to ban a single cheater from all subsequent rounds. In any case, it appears any alternation of the scheme that would work with the library would result in many more possible rounds as cheaters can get away with responding with invalid signature shares and entering new rounds.

An alternative to ROAST, might be to implement a synchronous protocol which would carry the potential for failures due to network delays.

Is it straight-forward to add ShareVal to this library and therefore make the ROAST scheme possible?

[conradoplg]

This should be feasible, we have the share validation logic, it's just not exposed in the API yet. We'll schedule the work to make this, thanks for pointing this out!

[conradoplg]

Can you double check if #727 solves your use case? Thanks!

[MatthewLM]

Thank you @conradoplg, it looks like verify_signature_share should be perfect. For my Taproot use-case, it is only further required that it is provided alongside #584.

[conradoplg]

Thank you @conradoplg, it looks like verify_signature_share should be perfect. For my Taproot use-case, it is only further required that it is provided alongside #584.

It's on our queue!