Stacker-signer State Maintenance and Honest Behavior

[kantai]

I'm not aware if this is all written down in full anywhere yet, so for my own edification, I tried to enumerate the complete state of the stacker-signer binary related to approving and rejecting blocks as well as constructing tenure change transactions.

State Maintenance

1. Current stacks miner
2. Current bitcoin block
3. Last stacks block approved by quorum (i.e., the threshold was reached)
4. Whether there is an ongoing approval (i.e., a block proposal is valid from the perspective of this stacker-signer, but we're waiting for the threshold to be reached).

Events

1. New bitcoin block arrives with sortition
   a. Update the "current stacks miner"
   b. Update the "current bitcoin block"
2. New bitcoin block arrives without sortition
   a. Update the "current bitcoin block"
3. New block proposal arrives via the StackerDB
   a. Is there an ongoing approval? if so, wait.
   b. does block build off of last approved?
   c. does block come from the expected miner?
   d. does block have latest bitcoin state?
   e. did the block validate via the stacks-node block proposal endpoint?
   f. if all of the above, begin a new approval process.
4. Tenure change request arrives (if tenure changes are requested by miners. if they are triggered by the stacker-signer binary itself, the process is similar, it's just that the request is self-generated on bitcoin block arrivals).
   a. Is there an ongoing approval? If so, wait.
   b. Does request match the current bitcoin block?
   c. Does request match the expected miner?
   d. Is the bitcoin block "stale" enough to issue an extension?
   e. If all of the above, construct a tenure change transaction and begin a new approval process.
5. Threshold reached on an approval process
   a. If for a new block, broadcast the block via the local stacks-node
   b. If for a tenure change transaction, broadcast via StackerDB
   c. If for a new block, update "last block approved"
   d. Release the "ongoing approval process" lock.

[jferrant]

Only thing is that first check should be "Do we have to run DKG" since can't begin signing blocks without it. But if this assumes that process is already done then it seems complete.

[kantai]

Yeah -- I think that should basically be an entirely separate mode of operation. None of the things above can proceed unless DKG has been completed. It makes me think it should be two different structs with two different run() methods -- when DKG completes, that struct exits and a new struct is constructed that handles block approvals.

[jferrant]

Possible, but I was under the impression that DKG could be rerun at any given time which makes me more inclined to not have two different structs as the signers must be able to handle a request to run a new DKG round.

[kantai]

I think even in that case, separate state-machines might make more sense: the process of DKG is just pretty unrelated to all the concerns of validating blocks. If DKG can proceed while the signer is still validating blocks, it probably makes sense to have two parallel state machines -- otherwise, the "validator" could end up using the wrong aggregate-key state, etc. If DKG and validation are mutually exclusive activities, then the validator should be destructed when the DKG state machine initializes.