MerosCrypto / Meros

An instant and feeless cryptocurrency for the future, secured by the Merit Caching Consensus Mechanism.
https://meroscrypto.io
Other
83 stars 19 forks source link

DoS vector when creating transactions. #283

Open kayabaNerve opened 3 years ago

kayabaNerve commented 3 years ago

This is possible due to a three-fold scenario:

1) Lack of threading when generating work - which goes back to our lack of multithreading.

2) 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).

3) 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.