You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently signers will count any block proposal that passes initial checks towards miner activity. However, a signer should be smarter about what counts as activity as a miner could simply having an outdated view or it could actually be a bad tenure where that miner will either not catch up/is misconfigured/is malicious.
Add a database table that tracks consensus hash to a last active timestamp. This last active timestamp should be used in the is_timed_out fn check in chainstate.rs. If a tenure has not had a single approved block, check this last active timestamp against the block_proposal_timeout.
This timestamp should get updated if a block proposal tries to reorg the last block of the prior tenure but only within a certain number of seconds of the tenure start and only block proposals at the tenure change boundary really matter. I.e. these block proposals will also have to pass tenure change transaction validity checks. It may need to accomodate locally vs globally accepetd block reorg attempts as well.
The text was updated successfully, but these errors were encountered:
jferrant
changed the title
[Signer] Miner activity should be only count specific bad block proposals
[Signer] Miner activity should only count specific bad block proposals
Jan 27, 2025
Currently signers will count any block proposal that passes initial checks towards miner activity. However, a signer should be smarter about what counts as activity as a miner could simply having an outdated view or it could actually be a bad tenure where that miner will either not catch up/is misconfigured/is malicious.
Add a database table that tracks consensus hash to a last active timestamp. This last active timestamp should be used in the
is_timed_out
fn check inchainstate.rs
. If a tenure has not had a single approved block, check this last active timestamp against theblock_proposal_timeout
.This timestamp should get updated if a block proposal tries to reorg the last block of the prior tenure but only within a certain number of seconds of the tenure start and only block proposals at the tenure change boundary really matter. I.e. these block proposals will also have to pass tenure change transaction validity checks. It may need to accomodate locally vs globally accepetd block reorg attempts as well.
The text was updated successfully, but these errors were encountered: