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 [email protected] 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

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

@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.

utACK

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

hard-fork or a soft-fork

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

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

Is this appropriate to backport to 0.11 and 0.10?

Yes, it should be also really simple to backport.

ACK for backport to 0.10 and 0.11