[Design]: Consider a duplicate multi-sig-address check from the smart contracts

[djordon]

Design - Consider a duplicate Multi-Sig Address Check from the Smart Contracts

1. Description

When executing rotate-keys contract calls, we used to perform a check to see whether the new multi-signature (multi-sig) address has been used before. We have removed this check, but maybe we should add it back.

1.1 Context & Purpose

The rotate-keys contract call does two things:

1. It potentially changes control of the sBTC smart contracts to another multi-sig wallet.
2. It updates the aggregate key used to lock deposits on Bitcoin.

Requiring that the multi-sig wallet never reuses a previous address is equivalent to requiring a new private key for any change to the signer set. This includes scenarios where a signer leaves the signer set and later rejoins. Although this may be a good idea, it's not strictly required and makes the network less flexible in situations where we are bootstrapping the system, as we are now.

It makes sense to require the aggregate key to change since the assumption is that this key is generated randomly each time. However, the multi-sig is formed using the public keys that the signers use to identify themselves over their peer-to-peer network. That public key is much more stable than the one generated during distributed key generation (DKG). Therefore, we should consider having a different assumption regarding how stable it actually needs to be.

3. Related Issues and Pull Requests (optional)

• The protocol involves several keys (summarized at Issue [Feature]: Realign on usage of distributed key generation outputs #614)
• Pull Request adding the checks: Bootstrap Signer Setup #151
• Pull request removing the checks: fix: demo branch fixes #920

4. Appendix

We haven't codified when DKG is necessary. One possible scenario is:

1. The signing set has 15 members, and one needs to drop out due to infrastructure problems.
2. We program the signers to detect this issue, run DKG automatically, and submit a rotate-keys contract call.
3. Later, that one signer wants to rejoin because their infrastructure is now functional. The other signers consider the signer who dropped off as valid (they're stacking the right amount), so their public key is perfectly fine.
4. They run DKG again and issue a rotate-keys contract call.
5. Under the current contract, this rotate-keys call would fail unless the new signer changed their private key and we also had a way to inform the signers which public keys are the correct ones.

Perhaps the expected behavior in this kind of scenario is the right onw, but it's also not clear which attack vector this check is addressing. Maybe that is the real question. Currently, the check is causing some issues for us on testnet.