Mark blocks with too many sigops as failed #7217

pull sdaftuar wants to merge 1 commits into bitcoin:master from sdaftuar:fix-sigops-rejection changing 1 files +1 −1

sdaftuar commented at 8:46 PM on December 15, 2015: member

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.
Mark blocks with too many sigops as failed 5246180f16
TheBlueMatt commented at 9:24 PM on December 15, 2015: member
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 --

#7217.patch #7217.diff

Reply to this email directly or view it on GitHub: #7217
sipa commented at 9:49 PM on December 15, 2015: member

A relayer cannot cause this error to trigger without also causing one of the real corruption-possible checks to fail, so concept ACK.
TheBlueMatt commented at 9:57 PM on December 15, 2015: member

@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 added the label Validation on Dec 17, 2015
laanwj commented at 11:02 AM on January 5, 2016: member

utACK
laanwj merged this on Jan 5, 2016
laanwj closed this on Jan 5, 2016
laanwj referenced this in commit a10a7920c3 on Jan 5, 2016
laanwj referenced this in commit e08b7cb33c on Jan 5, 2016
rebroad commented at 12:00 PM on January 5, 2016: contributor

Will this cause a hard-fork or a soft-fork?
MarcoFalke commented at 12:09 PM on January 5, 2016: member

hard-fork or a soft-fork

neither, we'd already never accept such blocks, iiuc?
pstratem commented at 7:06 PM on January 5, 2016: contributor

@rebroad neither, this just has to do with avoiding downloading the block in a loop
luke-jr commented at 1:33 AM on January 10, 2016: member

Is this appropriate to backport to 0.11 and 0.10?
sipa commented at 2:26 AM on January 10, 2016: member

ACK for backport
jtimon commented at 6:27 PM on January 11, 2016: contributor

Yes, it should be also really simple to backport.
sdaftuar commented at 6:43 PM on January 11, 2016: member

ACK for backport to 0.10 and 0.11
DrahtBot locked this on Sep 8, 2021

Contributors

Labels