Since Forknote made it really easy to create new coins, there has been constant fight against coin developers and miners with powerful Xeon clusters, FCPGA chips and ASIC devices.
There is three main methods of fighting against miners having too big percentage of total hashing powers:
- Constantly change hashing algorithm
- Change to difficulty algorithm that resists abrupt changes in hashing power
- Change block validation rules
- to disallow blocks with too small number of transactions
- to require minimum time between two consecutive blocks
Disadvantage of changing hashing algorithm is that new algorithms need to be supported by major hashing software and making hashing algorithm more complex means miners with lower end hardware usually have bigger penalty.
Disadvantage of changing difficulty algorithm is that it usually takes quite many blocks before the effect is noticeable.
Changing block validation rules to require minimum number of transactions means that if there is periods with no new transactions, it will drive difficulty of next block really low and that means when there is more transactions, those will be really easy to add to new blocks and soon there will be no more transactions again. This will eventually lead to situation where blocks are solved only during certain hours and rest of the day there is periods when no or very few blocks are solved.
To effectively fight against single miner having more than half of the hashing power, coin developer needs to use combination of different methods, so there will always be at least minimum number of transactions waiting in transaction pool but only during short period that happens close to target time between blocks.
Essentially daemon compares current time to timestamp of previous block and doesn't return block template if the time difference is too small. To avoid time between blocks to constantly grow too long, the minimum time difference should take account the time average miner takes to solve the block.
As the verification will be done both when the unsolved block template is returned and when the solved block is synchronized with other nodes, there is no advantage in tampering with the timestamp. Remote nodes will reject any block where the timestamp is too far in the future.