I'm not personally a fan of ROAST, due to resource intensity by eager execution, yet it's somewhat comparable to how Monero currently handles multisig. Monero will preprocess for all possible combinations and then... This preprocesses for all combinations with a specific inclusion criteria such that is doesn't spawn n * t sessions yet (n - t + 1). It's why I flagged it to koe during my recent review.

Regarding blame, Monero's KEX would need every key to have a verification share known by all other parties (which I don't believe it does). With that requirement, there's no reason sign couldn't be edited to include blame.

... unless the n-1 behavior causes that to form an exponential space requirement. That would make having verification shares impossible. I'd have to double check there.

Regardless, modernization of the multisig algorithm to FROST should be a no-brainer at this point.

kayabanerve[m]: the n - t + 1 looks like it's just for selecting the coordinator for signing. ROAST still expects every permutation of signer groups (that contain no flagged malicious players) during a message signing attempt. It seems like a decent generalization. However, in practice you usually have a fixed coordinator (i.e. whoever originally proposes 'lets sign this message'), and depending on use-case, you can remove some

members from consideration during signing (that's what my 'signer set filters' enable) to reduce network/computation costs (i.e. non-malicious players who may not be the targets of a signing attempt).

<UkoeHB> "kayabanerve: the n - t + 1 looks..." <- I believe it only tries n-t+1 simultaneously which is the point

Not that it isn't theoretically capable of trying a specific combination

That's why it even applies to large groups whereas monero caps at 16

> ROAST starts at most 𝑛 − 𝑡 + 1 concurrent

signing sessions of an underlying semi-interactive threshold signa-

ture scheme Σ, making it practical even for large choices of 𝑛 and

𝑡.

To be clear, 16 is needed for a few reasons. One of them being the preprocessing for all possible combinations. I think 33-50 generates 400 TB of data.

kayabanerve[m]: oh I may be misreading it "Since ROAST initiates at most 𝑛−𝑡 +1 signing sessions before successfully producing a signature, the coordinator will deliver a signature after at most 1 + 2(𝑛 − 𝑡 + 1) = 2(𝑛 − 𝑡) + 3 asynchronous rounds." (section 4.3). I guess it is n - t + 1 sequential sessions each for a signing group of size t, to iteratively find a group of t honest signers. Instead of just

trying all possible groups in parallel.

Ah, section 4.4 says to use n - t + 1 parallel coordinators if your coordinators are untrusted

Right

UkoeHB: AKA leaderless. Just have everyone be a coordinator.

I feel like their model doesn't really take into account nuances around the meaning of 'not honest'. A signer could be intermittently responsive, could have a fickle opinion about a message to sign, etc. Their model only guarantees success if there are t 'always online and cooperative' signers.

Though I guess 'eventually terminates' covers those possibilities... I'm mostly left wondering under what conditions their model would actually be useful.

I personally just prefer a x second timeout :p