Skip to content
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

Mark blocks with too many sigops as failed #7217

Merged
merged 1 commit into from Jan 5, 2016

Conversation

@sdaftuar
Copy link
Member

sdaftuar commented Dec 15, 2015

This unsets the "corruption possible" field in CValidationState when calling CheckBlock on a block with too many sigops. Without this change, bitcoind would re-request such a block rather than mark it as permanently failed.

@TheBlueMatt
Copy link
Contributor

TheBlueMatt commented Dec 15, 2015

Hmm, that one's fun.... Yea, thinking briefly about it I don't see how that error could indicate block malleability.

On December 15, 2015 12:46:54 PM PST, Suhas Daftuar notifications@github.com wrote:

This unsets the "corruption possible" field in CValidationState when
calling CheckBlock on a block with too many sigops. Without this
change, bitcoind would re-request such a block rather than mark it as
permanently failed.
You can view, comment on, or merge this pull request online at:

#7217

-- Commit Summary --

  • Mark blocks with too many sigops as failed

-- File Changes --

M src/main.cpp (2)

-- Patch Links --

https://github.com/bitcoin/bitcoin/pull/7217.patch
https://github.com/bitcoin/bitcoin/pull/7217.diff


Reply to this email directly or view it on GitHub:
#7217

@sipa
Copy link
Member

sipa commented Dec 15, 2015

A relayer cannot cause this error to trigger without also causing one of the real corruption-possible checks to fail, so concept ACK.

@TheBlueMatt
Copy link
Contributor

TheBlueMatt commented Dec 15, 2015

@sipa and I went back and traced the blame for that line...it looks like when the corruption possible flag was set for this case, it was, indeed needed as it was checked before the merkle tree was checked. As the order has now changed we do, indeed, no longer need this check.

@laanwj laanwj added the Validation label Dec 17, 2015
@laanwj
Copy link
Member

laanwj commented Jan 5, 2016

utACK

@laanwj laanwj merged commit 5246180 into bitcoin:master Jan 5, 2016
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
laanwj added a commit that referenced this pull request Jan 5, 2016
5246180 Mark blocks with too many sigops as failed (Suhas Daftuar)
laanwj added a commit that referenced this pull request Jan 5, 2016
Github-Pull: #7217
Rebased-From: 5246180
@rebroad
Copy link
Contributor

rebroad commented Jan 5, 2016

Will this cause a hard-fork or a soft-fork?

@MarcoFalke
Copy link
Member

MarcoFalke commented Jan 5, 2016

hard-fork or a soft-fork

neither, we'd already never accept such blocks, iiuc?

@pstratem
Copy link
Contributor

pstratem commented Jan 5, 2016

@rebroad neither, this just has to do with avoiding downloading the block in a loop

@luke-jr
Copy link
Member

luke-jr commented Jan 10, 2016

Is this appropriate to backport to 0.11 and 0.10?

@sipa
Copy link
Member

sipa commented Jan 10, 2016

@jtimon
Copy link
Member

jtimon commented Jan 11, 2016

Yes, it should be also really simple to backport.

@sdaftuar
Copy link
Member Author

sdaftuar commented Jan 11, 2016

ACK for backport to 0.10 and 0.11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants
You can’t perform that action at this time.