Nakamoto Signer[3.0] - Coordinator selection revamp

[jferrant]

Currently coordinator selection is done with a zeroed consensus hash just to enable tests to pass . There needs to be a revamp of the selection logic. The chain tip consensus hash may not be sufficient.

One of the biggest issues is that signers do not necessarily come online at the same block height, they all have different consensus hash tips and they all start triggering DKG and clobber each other. Part of the problem is we don't have a good way of aborting DKG rounds in favour of another (I think Marzi's PR may help with this)

The other problem is that combined with these timeouts ^ if the intiial coordinator selection is different for everyone, they allw ait for their cooridnators to exceed a timeout before choosing a new one which is also bad. I think a better solution is to have the initial coordinator list be calculated at a very specific block height such as the block at which a reward set was calculated. This will ensure that the coordinator list is globally the same, not predictable, but always the same for all signers regardless of their view. Signers just iterate that list as they do now if a cooridnator is unresponsive. Of course to ensure the coordinator does change for a reward cycle and its not just all on one signer, we could also have the selection list update by consensush hash, calculated at some set number of blocks away from the initial block height.

Does this make sense ^? Not sure about how to calculate unresponsiveness . I assume we could just use the burnchain tip height rather than the stacks node? so we don't have a timing skew?

[jferrant]

This is not technically done. We only have addressed the coordinator issue for signing and not DKG.

[saralab]

• Miners need to select a coordinator during DKG
• Decision on how to pick to the coordinator pending
• how to pick a coordinator if there is none vs if there is a functional coordinator
• Re-running DKG
• decision: If we can run DKG with a smaller set of signers

[jferrant]

When a new coordinator is selected by a signer, they may need to reread stackerdb slots to catch up their view point to be the same as other signers (i.e. they may have previously ignored coordinator messages for a particular round due to a stale viewpoint.) There is already this functionality in place when a signer comes online for the first time. We should probably just enforce it every time the coordinator changes as well in case the signer has previously ignored a coordinator message due to their outdated view of the current coordinator.

When a new coordinator begins its tenure, it should not necessarily abort the current DKG round (it has all necessary info to just continue it if desired)

[netrome]

Closing this since the coordinator is being revamped separately with larger changes planned.