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
When a signer gets a block validation response back from its node, it first checks if it has locally marked the block as GloballyAccepted or GloballyRejected. If this is the case, the signer doesn't broadcast a BlockResponse.
It would be better for the signer to still broadcast a block response, for a few reasons:
Even if this signer has seen enough responses to mark the block as accepted, the miner and/or other signers might not have
For monitoring purposes, it's better to know that a signer broadcasted a block response a little slower than others, than to not know if the signer was "alive" or not
With potential behavior around withholding of PoX rewards, we don't want to be penalizing just because a signer is in the >70%th latency percentile for a block
When a signer gets a block validation response back from its node, it first checks if it has locally marked the block as
GloballyAccepted
orGloballyRejected
. If this is the case, the signer doesn't broadcast aBlockResponse
.It would be better for the signer to still broadcast a block response, for a few reasons:
Relevant code:
stacks-core/stacks-signer/src/v0/signer.rs
Lines 497 to 509 in db35bfe
The text was updated successfully, but these errors were encountered: