[SPEC] Key refresh using DKR methods

[drewstone]

Overview

We want to implement a key rotation using a distributed key refresh protocol wherein the group keypair remains the same.

Currently in the DKG, we re-run the protocol entirely and sign the new key with the active key, eventually rotating this if the signature is valid and verifies on-chain.

Checklist

• [ ] Implement a new Refresh async protocol handler
• [ ] Implement a new set of gossip messages relevant for Refresh protocol
• [ ] Define the joining process. Obviously queued authorities are selected by design, what else do they need to do now? What do existing authorities need to do? What happens when either fails to do their job?
• [ ] Define new misbehaviour cases.

Research

https://github.com/ZenGo-X/fs-dkr

Examples

https://github.com/ing-bank/threshold-signatures/blob/master/src/ecdsa/resharing.rs

Questions/Issues

The security assumptions and implementations do change ofc. These protocols usually can't guarantee that parties have thrown away their old keys. This does diminish over time but it does allow for different adversaries to tamper with the network in different models.

[dutterbutter]

@drewstone can you please provide more details here.

[drewstone]

Selecting new authorities

Bootstrapping off of the session change mechanism, we currently expect the queued authorities to run the DKG. Here, we similarly may expect the queued authorities to run the DKR. To this end, we need to identify what is necessary for running the DKG.

1. There is a JoinMessage that is needed for participating, how will queued authorities submit this? What part of this message needs to be submitted on-chain and verified? Will any part of it be on-chain?
   • What if a queued authority doesn't submit a join message? Should this be possible or should it be forced on-chain to submit this data?