-
Notifications
You must be signed in to change notification settings - Fork 685
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Miner implementation does not correctly walk mempool #2389
Comments
In the
|
kantai
added a commit
that referenced
this issue
Jan 29, 2021
Fix: #2389 Mempool walks, add `try-mine` CLI command
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
# for free
to subscribe to this conversation on GitHub.
Already have an account?
#.
In order to "walk" the mempool and find transactions for inclusion in a block, a miner does the following (starting at block height n)
(consensus_hash, block_hash)
pairs at height nconsensus_hash, block_hash
pair for the current chain's view of height nSteps 1->2->3 have a (breaking) logic bug: if the mempool db doesn't have any entries for a block's ancestor, then the walk stops. This, however, is entirely possible, and would be expected to occur 50% of the time if there is a short-lived fork and this has happened a few times over the course of the Stacks chain so far.
For example, at block 1631:
In step (1), the mempool will only ever have entries for a given block height on the fork it followed (in 1631's case, the a node believed
51d33db6d82374122349314a1c582909dca473ce/adfa719db9a3ccb47b21e55a8a7f60d0bac4a51d9a266851ea8c2a41df49ae70
to be the chain tip).But, 1632 is mined by someone with a different height 1631 block. 1632's parent block is
3152453237a1a030320b168d87555c18a6942893/8819f44ab05b1130cd053052400bcaaa64a27a58dbc55db600c8dbe878ae5428
Once this occurs, any node that had a different 1631 height view will never consider for inclusion a transaction that they first received earlier than that block height.
Fixing this is not consensus-breaking, but would require miners themselves to upgrade.
The text was updated successfully, but these errors were encountered: