Feature - Allow FIRE coordinator to set the participation threshold for signing rounds
1. Description
Right now the FIRE coordinator will always proceeds with a signing round if it gets nonce responses from a threshold of signers. This is usually optimal, but we would like to be able to change this behavior so that the coordinator waits for nonce responses from all signers. We would use this behavior in the sbtc repo when doing DKG verification, where we want to wait on responses from all signers before proceeding. Right now we use the FROST coordinator for this behavior, which is less than ideal since the two coordinators are a bit different.
2. Technical Details:
I see two paths that we could take here.
- Add a parameter that allows the user to specify the exact number of signers to wait on nonce responses from before proceeding with the signing round.
- Add a parameter that allows the user to change the behavior to wait for responses from all signers.
I propose that we do (1), since I can see a use for that functionality in sBTC as we work to open the signer set. However, we can work toward it and just start with (2), since it's easier.
Note: I do not really want to support the requested behavior, since it's a strange use case. But one nice thing about doing this is that we could then remove the FROST coordinator since the behavior should then be entirely subsumed by the FIRE coordinator.
2.1 Acceptance Criteria:
3. Related Issues and Pull Requests (optional):
Feature - Allow FIRE coordinator to set the participation threshold for signing rounds
1. Description
Right now the FIRE coordinator will always proceeds with a signing round if it gets nonce responses from a threshold of signers. This is usually optimal, but we would like to be able to change this behavior so that the coordinator waits for nonce responses from all signers. We would use this behavior in the sbtc repo when doing DKG verification, where we want to wait on responses from all signers before proceeding. Right now we use the FROST coordinator for this behavior, which is less than ideal since the two coordinators are a bit different.
2. Technical Details:
I see two paths that we could take here.
I propose that we do (1), since I can see a use for that functionality in sBTC as we work to open the signer set. However, we can work toward it and just start with (2), since it's easier.
Note: I do not really want to support the requested behavior, since it's a strange use case. But one nice thing about doing this is that we could then remove the FROST coordinator since the behavior should then be entirely subsumed by the FIRE coordinator.
2.1 Acceptance Criteria:
3. Related Issues and Pull Requests (optional):