Miner changes for time-based tenure extends #5493
Conversation
With this change, the signer will accept a tenure extend from miner N-1 when miner N wins a sortition but commits to the wrong parent tenure.
The previous design using a global singleton causes trouble in testing, when we have multiple miners running in different threads of the same process.
This is useful when checking the behavior during forking.
`SignerDBListener` struct is for a new thread that is always processing StackerDB messages from the signers during a mining tenure. `SignerCoordinator` is the interface that the miner uses with the `SignerDBListener`, to propose a block and wait for signatures.
|
Should the |
Oh, right. It's signer messages in the stacker db. I guess the signerdb is another thing. Oops. Thanks! |
There was a problem hiding this comment.
My biggest feedback here is that the code mixes a lot of low-level thread synchronization code into the business logic, which I think is something we should strive to avoid. The synchronization logic may change down the road depending on what other threads need to interact with signature-gathering, so we should do what we do elsewhere and wrap all of the thread synchronization / state-sharing behind a "Comms" struct, and provide methods there that better reflect the business logic's needs.
|
Note to reviewers - there is an integration test for this behavior in #5471. |
Fixed. I previously failed to commit one of the changes for one of those refactorings. |
obycode
merged commit 061da00
into
feat/time-based-tenure-extend
See #5468
This currently also includes #5452, since it has changes that would conflict. Once that is merged into
develop, I will mergedevelopintofeat/time-based-tenure-extendand then clean this branch up.