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
Lack of threading when generating work - which goes back to our lack of multithreading.
Lack of a cap on how many proofs are attempted - when there likely shouldn't be one (4 byte proof for 2 byte difficulty means there should always be a solution; a check if we iterate over the entire solution field may be valuable).
The fact that the initial difficulty is overridden the second a vote is passed. This means the first person to vote for the diff can nuke it.
So this is only possible at the start of the network. Pending an intelligent algorithm on deciding the difficulty, not to mention retargeting, the following fix would work:
When Merit is first gained, if the height < X (start of network), vote for the initial difficulty. Else, vote for the current difficulty. This throws Merit into the pool stopping abuse of a lack of votes. It also should stop poisoning at the start of the network as a malicious actor would need the majority of blocks before X to attack the network as such.
Of course, Merit Holders will be able to manually specify a difficulty, so even in the worst case at the start of the network, we can recover (though such a situation has much more worrying aspects). The relevant RPC calls will be part of #279.
The text was updated successfully, but these errors were encountered:
This is possible due to a three-fold scenario:
Lack of threading when generating work - which goes back to our lack of multithreading.
Lack of a cap on how many proofs are attempted - when there likely shouldn't be one (4 byte proof for 2 byte difficulty means there should always be a solution; a check if we iterate over the entire solution field may be valuable).
The fact that the initial difficulty is overridden the second a vote is passed. This means the first person to vote for the diff can nuke it.
So this is only possible at the start of the network. Pending an intelligent algorithm on deciding the difficulty, not to mention retargeting, the following fix would work:
When Merit is first gained, if the height < X (start of network), vote for the initial difficulty. Else, vote for the current difficulty. This throws Merit into the pool stopping abuse of a lack of votes. It also should stop poisoning at the start of the network as a malicious actor would need the majority of blocks before X to attack the network as such.
Of course, Merit Holders will be able to manually specify a difficulty, so even in the worst case at the start of the network, we can recover (though such a situation has much more worrying aspects). The relevant RPC calls will be part of #279.
The text was updated successfully, but these errors were encountered: