Fix headers announcements edge case#7919
Conversation
Previously we would assert that if every block in vBlockHashesToAnnounce is in chainActive, then the blocks to be announced must connect. However, there are edge cases where this assumption could be violated (eg using invalidateblock / reconsiderblock), so just check for this case and revert to inv-announcement instead.
|
utACK |
|
utACK 3a99fb2 |
|
utACK 3a99fb2 |
|
utACK 3a99fb2 |
|
utACK 3a99fb2 On April 20, 2016 11:26:28 AM PDT, Suhas Daftuar [email protected] wrote:
|
3a99fb2 Fix headers announcements edge case (Suhas Daftuar)
Previously we would assert that if every block in vBlockHashesToAnnounce is in chainActive, then the blocks to be announced must connect. However, there are edge cases where this assumption could be violated (eg using invalidateblock / reconsiderblock), so just check for this case and revert to inv-announcement instead. Github-Pull: bitcoin#7919 Rebased-From: 3a99fb2
|
Backported as part of #7938. Removing label 'Needs backport'. |
Previously we would assert that if every block in vBlockHashesToAnnounce is in chainActive, then the blocks to be announced must connect. However, there are edge cases where this assumption could be violated (eg using invalidateblock / reconsiderblock), so just check for this case and revert to inv-announcement instead. Github-Pull: bitcoin#7919 Rebased-From: 3a99fb2
8 participants
Previously we would assert that if every block in
vBlockHashesToAnnounceis inchainActive, then the blocks to be announced must connect. However, there areedge cases where this assumption could be violated (eg using invalidateblock /
reconsiderblock), so just check for this case and revert to inv-announcement
instead.
FYI I encountered this bug once while running
mempool_packages.py, and was able to reproduce reliably by repeatedly invokinginvalidateblock/reconsiderblockon the tip.Perhaps we should backport this to 0.12 as well?