batch signature verification

[pro-wh]

In a discussion about the multisig configuration structure, regarding Batch which collects a slice of public keys and signatures for batch verification:

Why not do the actual verification? I'm of mixed opinion if a batch should fail if it as any invalid signatures regardless of threshold or not. The way this is setup right now is an all-or-nothing design as far as I can tell.

(I assume allowing a MultisigConfig with mixed public-key types is deliberate, though this will complicate batch verification logic.)

Originally posted by @Yawning in https://github.com/oasisprotocol/oasis-sdk/pull/118#discussion_r635272927

[Yawning]

we'll have to have an additional step to separate the public key types. but are we moving away from batch signature verification in general?

Why would we be? It is a net gain as long as the batch size is greater than 1, and can be implemented correctly, though only our Go verification code does so at the moment.

this isn't meant to be all-or-nothing. it'll leave out the nils from the signature set (Option in the rust side). we'd advise that the transaction sender nil out invalid signatures on their own and avoid submitting a transaction with some valid and some invalid signatures

If so, then what is the expected behavior if one signature out of a batch is invalid? It is fine if any invalid signatures fail the verify (all-or-nothing), but otherwise, I am expected to what, loop over the batch, adding up the thresholds that are valid?

So again, why not implement a more idiot-proof (misuse resistant) API that combines threshold calculation, batch verification, and signature verification?

[wh0]

If so, then what is the expected behavior if one signature out of a batch is invalid? It is fine if any invalid signatures fail the verify (all-or-nothing), but otherwise, I am expected to what, loop over the batch, adding up the thresholds that are valid?

I've been unclear, sorry. Once we get the batch from the Batch call, we'll verify all signatures in that batch, and this part specifically will be all-or-nothing.

So again, why not implement a more idiot-proof (misuse resistant) API that combines threshold calculation, batch verification, and signature verification?

The purpose of this is so that we can combine the signature sets from multiple multisig authentication slots and "single" signature slots into a single batch verification operation, for performance.