You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 toB (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.
The text was updated successfully, but these errors were encountered:
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:
With this proposal, votes for anything prior to
B
(the parent of the current tipC
) 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 (someA'
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 remineB
with more votes onA
or someA'
). 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.The text was updated successfully, but these errors were encountered: