Mark blocks with too many sigops as failed #7217

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.
2. Mark blocks with too many sigops as failed 5246180f16
3. 
   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

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

   utACK
8. laanwj merged this on Jan 5, 2016
9. laanwj closed this on Jan 5, 2016

   ---

10. laanwj referenced this in commit a10a7920c3 on Jan 5, 2016
11. laanwj referenced this in commit e08b7cb33c on Jan 5, 2016
12. 
    rebroad commented at 12:00 pm on January 5, 2016: contributor

    Will this cause a hard-fork or a soft-fork?
13. 
    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?

14. 
    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
15. 
    luke-jr commented at 1:33 am on January 10, 2016: member

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

    ACK for backport
17. 
    jtimon commented at 6:27 pm on January 11, 2016: contributor

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

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

Contributors
sdaftuar TheBlueMatt sipa laanwj rebroad MarcoFalke pstratem luke-jr jtimon

Labels
Validation