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
The nakamoto miner should behave a little less strictly when it comes to waiting for proposals:
If the miner sees that they have 20% rejections, and have already waited, e.g., 2 minutes, they should consider their proposal rejected. We could probably come up with some smooth function over the range [0, 30] which defines how long the miner should be waiting. If they haven't received any rejections, then wait forever (as is the current behavior), and if they've received >30% rejections, then abort immediately (as is the current behavior). In between, we want to do something more heuristic.
The nakamoto miner should behave a little less strictly when it comes to waiting for proposals:
If the miner sees that they have 20% rejections, and have already waited, e.g., 2 minutes, they should consider their proposal rejected. We could probably come up with some smooth function over the range [0, 30] which defines how long the miner should be waiting. If they haven't received any rejections, then wait forever (as is the current behavior), and if they've received >30% rejections, then abort immediately (as is the current behavior). In between, we want to do something more heuristic.
My guess is that we want something squared:
10 - 10*(x/30)^2
Or just something stepped:
0-10% rejection: wait 10 minutes
10-20% rejection: wait 5 minutes
20-30% rejection: wait 2.5 minutes
The text was updated successfully, but these errors were encountered: