-
Notifications
You must be signed in to change notification settings - Fork 37.7k
Keep mempool consistent during block-reorgs #5945
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
9861337
to
c22adce
Compare
I tested this. ACK. |
continue; | ||
txToRemove.push_back(it->second.ptx->GetHash()); | ||
} | ||
} | ||
while (!txToRemove.empty()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could use some comments saying what this block of code is intending to actually do; not obvious right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment added.
c22adce
to
ad9e86d
Compare
This fixes a subtle bug involving block re-orgs and non-standard transactions. Start with a block containing a non-standard transaction, and one or more transactions spending it in the memory pool. Then re-org away from that block to another chain that does not contain the non-standard transaction. Result before this fix: the dependent transactions get stuck in the mempool without their parent, putting the mempool in an inconsistent state. Tested with a new unit test.
Very much untested and rushed ACK |
Going to test this. |
Untested ACK. |
I was observed two crashes in 0.10rc1, each 24 hours apart with checkmempool=1 (and a non-default fee policy) during reorgs that appeared to be likely due to the bug this fixes. I've now run three days with this pull applied and no crashes, and there have been several reorgs during that time. |
Tested ACK |
ad9e86d Keep mempool consistent during block-reorgs (Gavin Andresen)
Backported to 0.10 branch as 8bb4abc19ae0e76424e69a19ff6fc31e5b044333 |
This fixes a subtle bug involving block re-orgs and non-standard transactions. Start with a block containing a non-standard transaction, and one or more transactions spending it in the memory pool. Then re-org away from that block to another chain that does not contain the non-standard transaction. Result before this fix: the dependent transactions get stuck in the mempool without their parent, putting the mempool in an inconsistent state. Tested with a new unit test (adapted for 0.10). Rebased-From: ad9e86d Github-Pull: #5945
This fixes a subtle bug involving block re-orgs and non-standard transactions. Start with a block containing a non-standard transaction, and one or more transactions spending it in the memory pool. Then re-org away from that block to another chain that does not contain the non-standard transaction. Result before this fix: the dependent transactions get stuck in the mempool without their parent, putting the mempool in an inconsistent state. Tested with a new unit test (adapted for 0.10). Rebased-From: ad9e86d Github-Pull: bitcoin#5945 (cherry picked from commit 1c62e84)
This fixes a subtle bug involving block re-orgs and non-standard transactions. Start with a block containing a non-standard transaction, and one or more transactions spending it in the memory pool. Then re-org away from that block to another chain that does not contain the non-standard transaction. Result before this fix: the dependent transactions get stuck in the mempool without their parent, putting the mempool in an inconsistent state. Tested with a new unit test (adapted for 0.10). Rebased-From: ad9e86d Github-Pull: bitcoin#5945 (cherry picked from commit 1c62e84)
This fixes a subtle bug involving block re-orgs and non-standard transactions.
Start with a block containing a non-standard transaction, and
one or more transactions spending it in the memory pool.
Then re-org away from that block to another chain that does
not contain the non-standard transaction.
Result before this fix: the dependent transactions get stuck
in the mempool without their parent, putting the mempool
in an inconsistent state.
Tested with a new unit test.
Thanks to Alex Morcos for finding the bug.