Don't validate blocks with fork number greater than the version fork number #7
Conversation
| InvalidAdjacentVersion -> "An adjancent parent has a chainweb version that does not match the version of the validated header" | ||
| IncorrectForkNumber -> "The block has an incorrect fork number" | ||
| InvalidForkVotes -> "The block has an invalid fork vote count" | ||
| UnknownForkNumber -> "The block has an unknown fork number" |
There was a problem hiding this comment.
I assume this msg is shown in the log. I suggest helping the node operator and add "The node is likely outdated and require an upgrade"
There was a problem hiding this comment.
I remember having this thought, then deciding against it, and now I can't think of any good reason to 😅 done.
| , IncorrectGenesisTarget | ||
| , IncorrectPayloadHash | ||
| , IncorrectForkNumber | ||
| , UnknownForkNumber |
There was a problem hiding this comment.
I think, we shouldn't blacklist peers for that reason. Because we are probably the culprit here.
There was a problem hiding this comment.
If we don't blacklist a peer on a different fork number, we may waste local and remote peer resources attempting to share blocks with them and catch up to their blocks; and in general, there is not much reason to share a mempool with the peer either, because the likelihood is that transactions will not be valid between the two forks and replaying transactions across forks is likely not desired behavior.
definiteValidationFailures specifically denotes validation failures which indicate that there is a difference in block validation behavior; this is exactly a hard fork, and fork numbers are hard forks by definition.
edmundnoble
force-pushed
the
push-ssotmopxotyl
branch
from
5a26bd7 to
58681f6
Compare
No description provided.