-
Notifications
You must be signed in to change notification settings - Fork 20.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd, core, miner: add extradata validation to consensus rules #2794
Conversation
Updated: Sat Jul 16 10:09:55 UTC 2016 |
if self.config.DAOForkSupport { | ||
header.Extra = common.CopyBytes(params.DAOForkBlockExtra) | ||
} else if bytes.Compare(header.Extra, params.DAOForkBlockExtra) == 0 { | ||
header.Extra = []byte{} // If miner opposes, don't let it use the reserved extra-data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the intent of this line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent is that a non-forking user might set extra-data from the command line to the one used by forkers, just to wreck havok in the "other" camp. This is just a check to remove naive attempts at that. It's not a fool proof solution of course, just a nicety to try and prevent people doing bad things with little effort.
Superseeded and merged in #2814. |
Prerequisite PRs, merge these first to get rid of duplicate commits:
This PR makes the necessary consensus modifications to header validation rules so that block header
extraData
fields are enforced to be either0x64616f2d686172642d666f726b
(hex fordao-hard-fork
) for pro-forkers or everything but that for non-forkers. These rules are upheld for10
blocks straight to protect both forkers and non-forkers against malicious actors of the opposite side.Since non-forkers also need to know the actual DAO hard-fork block number to enforce themselves onto the opposite side of the network (i.e. a non-forker fast syncing needs to be aware of the headers it needs to check), this PR makes a further modification to the previous chain configurations so not only a single
ChainConfig.DAOForkNumber
is maintained (previously implicitly signalling pro-fork), but rather an explicitChainConfig.DAOForkSupport
boolean flag is added too. This way both camps can maintain the block numbers whilst also allowing both decisions.