When submitblock of an invalid block, the return value should not be "duplicate".
This is only seen when the header was previously found (denoted by the incorrectly named boolean fBlockPresent). Fix this bug by removing fBlockPresent.
When submitblock of an invalid block, the return value should not be "duplicate".
This is only seen when the header was previously found (denoted by the incorrectly named boolean fBlockPresent). Fix this bug by removing fBlockPresent.
<!--e57a25ab6845829454e8d69fc972939a-->Note to reviewers: This pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
Is @DrahtBot a new addition to the project? Who is the bot owner? :-)
An evil paperclip robot, I don't know whose it is. But it seems useful.
utACK fa4125621554f2f94fded1896ba7eae10ef954da
utACK fa41256. Nit, Result: help could be improved.
This breaks having two submitblocks in paralell. Now instead of one returning true and the other duplicate, you might have one return true and one simply return "inconclusive". I think the correct fix is to just set fBlockPresent to pindex->nStatus & HAVE_DATA.
@TheBlueMatt I don't see how this fixes the race. The only other option I see is to partially revert the commit that introduced the bug (eb63bf86cf6dc99f150574463df6ffb013a34493), i.e. read from mapBlockIndex after ProcessNewBlock.
Ah, indeed, must have been introduced on master when ProcessNewBlock lost its cs_main at call-time. Obvious fix would be to duplicate the fBlockPresent check after PNB by re-acquiring cs_main.
utACK
Maybe DrahtBot can rebase my PR for me once this is merged ;-)
I force pushed the commit with two changes:
return "duplicate" when fNewBlock is given as false from PNBShould be easy to re-ACK
utACK fa08ebd7f24fc911b1af14644e4e235b6f3f9316
re-utACK fa08ebd.
Why close?
Why close?
To indicate that it was up for grabs.
To indicate that it was up for grabs.
I don't get it. If this is up for grabs you think it should be merged, but you don't want to maintain it? It's currently mergeable and has ACKs. Why not just leave it open?
Please see #13439. The changes here weren't sufficient, needed one more commit to actually fix the issue mentioned.
Got it. Good to know. Thanks Matt!