Skip to content
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

[mempool] Votes on blocks prior to the parent of the current tip should be pruned. #1130

Open
davecgh opened this issue Mar 6, 2018 · 0 comments

Comments

@davecgh
Copy link
Member

davecgh commented Mar 6, 2018

Currently, votes in the mempool that do not make it into a block are not pruned until after 10 blocks have passed. As noted in #4, this is also being based on the height they entered the pool instead of for the block they actually vote on.

I would like to propose that this should be changed so that votes are pruned once the block they vote on is prior to the parent of the current tip because there really is not a very good case (discussion follows) for going back further than the current parent since that parent is the most proof-of-work block and it very clearly had the votes necessary for its formation to begin with.

For a concrete example, assume the following chain:

A -> B -> C  -> ? <---- not enough votes for C, so miners have to go back and find a new C (call it C')
      \-> C'

With this proposal, votes for anything prior to B (the parent of the current tip C) would be pruned.

A potential objection that might come up is the case where that parent (B in the diagram above) contained less than 5 votes for the grandparent (A in the diagram) and more votes have since shown up, either for the grandparent (A) or an alternate grandparent on a side chain (some A' not depicted). In that scenario, it might be argued that miners could go back an additional block in order to favor that block with more votes (that is to say to remine B with more votes on A or some A'). In order to have that option, those votes would need to be permitted to the mempool so they are known and available.

However, this, in my opinion, is not a realistic objection because it is incredibly unlikely that any rational miner would ever choose to do that because it would put them at a severe disadvantage as compared to any miners who opted not to since the latter would have a full block (the block with <5 votes, B) head start on them and thus it would be nearly impossible for those miners attempting to remine an alternate parent to have their block end up becoming the longest chain as it would be similar to trying to 51% the network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant