Nakamoto: Allow miner to reorg in poorly timed tenures #4956
Conversation
* track sortition timing * track proposal timing * make proposal / sortition timing configurable
kantai
force-pushed
the
feat/signer-block-timing
branch
from
e02b6d7
to
c524b3a
Compare
Yep -- added 2 integration tests in 62aac67 which test the reorg handling. The reason there's two integration tests is that I want to test both the behavior when a reorg should be allowed and when it shouldn't. To do that, I change the configured allowable time between the proposal being approved and the next sortition. It would be possible to do this in a single test with just 1 setting of that configuration, but at that point, the test would become much more sensitive to timing, which would probably make it flap in CI. |
|
Before I approve again, looks like there are still some rust format issues to resolve. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This implements a fix for #4844, by adding a check to the signer's chainstate validation checks. This check allows reorgs to occur in the case that the reorged tenure's first block occurred very near the time that the next sortition occurred.
Currently, this check compares the proposal's arrival time with the time that the signer learned about the next sortition. This is a pretty conservative duration -- something more aggressive would compare the proposals "sign off" time with the sortition's arrival time. I'm not sure which approach would be better actually, so this PR just implements the simplest one for now.
This is tested via two new unit tests in the stacks-signer package.