Hi all,
First, an encouragement: I just added another 40kH/s to p2.pool mini.
I have been following Monero for some time, since around 2017, but usually keep to myself. I’ve just a couple of days ago had an idea though for improving 51% attack resistance, so I made an account in order to share that idea.
Proposal Overview The idea is to give a difficulty penalty to new hash power in order to make 51% attacks more expensive. This would penalise short term hash rate increases whilst minimising the impact to long term legitimate miners.
How It Would Work
- Hash Rate Verification: Block producers (solo miners, or pools, treated as solo miners) periodically prove their hash rate to the protocol (e.g., 10 times daily).
- Perhaps prove hash rate by submitting shares.
- Difficulty Penalty: If a miner’s hash rate spikes significantly, the protocol applies a higher difficulty to their new hash rate, reducing its effectiveness in mining blocks.
- A miner’s difficulty would be an average of the standard network difficulty (for their existing hash rate) and a higher difficulty (for their additional hash rate) weighted by percentage of each.
- Normalisation Over Time: The penalty gradually decreases over, say, 3 months, as the new hash rate is sustained, the miners average hash rate trends towards it.
- Seasonal Miner Adjustment: A separate, decay rate applies to hash rate reductions which can be tuned to avoid overly penalising legitimate fluctuations such as seasonal miners who mine less during warmer months or those who mine on intermittent power sources such as wind or solar power.
- The hash rate of a miner must decay to prevent a malicious actor ‘levelling up’ many miners and then utilising rented hash rate across them all at the same time later for an attack.
Benefits
- An increase in the cost to 51% attack the network by:
- Requiring more hash power, to overcome the difficulty penalty or,
- Forcing an attack to operate over a longer time frame, increasing the amount of time the hash rate is required for.
- Encourages legitimate, stable, long term mining of Monero, by providing a disincentive to short term pool swapping and gaming the difficulty adjustment speed by intermittently mining with a high hash rate.
Possible Challenges
I’m not a software engineer, so I’d like feedback on these potential issues:
- Barrier to Entry: The difficulty penalty will also affect new legitimate miners. How could the penalty be tuned to minimise this?
- Privacy Concerns: Proving hash rate may require identifying miners to the protocol. Is there cryptographic way to anonymize this?
- Resource Demands: Tracking hash rates could strain bandwidth or storage for nodes. Could pruning old data (e.g., after 3 months) address this?
- Cost of Defensive Hash Rate: Adding hash rate to defend the network during an attack would also face the penalty. Would this at least be no worse than how it is today, as defensive hash rate has equal power against an attacker?
- Implementation: Could this be done in Monero’s protocol? Are there similar mechanisms in any other blockchains?
I’m interested to hear what others think and whether or not you can see any other challenges or deal-breakers for this defensive mechanism.
nothing prevents you to create another “identity” to avoid penalty.
Thanks for the feedback.
As I see this idea operating, any new identity would have an average hash rate of zero to begin with (say the protocol assumes a new identity has hashed at 0H/s for the infinite past), which would mean that starting a new “identity” results in a penalty on any hash rate attributed to that identity. This means that the economic incentive is to stay using the identity you already have.
Also noticed that, in order to preserve the block time, the average difficulty network wide would need to remain constant. This means that in the event of a large attack, because of the higher difficulty applied to the attackers hash rate, the standard network difficulty would need to drop, effectively giving existing long term miners a further advantage over the attacker.
Thank you for supporting the network!
Right now the difficulty setup of the mining is the same for all the miners.
All the miners are trying to solve the same equation, randomly trying this or that value to see if it matches.
The first one to propose a value that solves the equation gets to mine the new block and gets the block reward.
When new miners join in, there is no mechanism to differentiate them, from the protocol’s POV. If a miner joins p2pool there are things there to identify them, but not on the general Monero protocol.
In the general Monero protocol, you just need to be the first to find a solution to the equation and propose the new block. You don’t even have to be the one that mined it (found the solution and proposed the block) you just need to send it, so someone could do all the heaving mining and send you the new block and you will be the first one to send it to the network.The way the protocol manages miners arriving and leaving is via the difficulty adjustment. When a lot of new miners join, the increased hash rate will make it easier to find the solution to the equation, so new blocks will come more often.
That means that the time between blocks will be less than the desired 2 minutes. After a while, the protocol will notice that and increase the difficulty so that we get back to 2 minutes. The same happens when miners leave, there is less computational power to find the new blocks, it takes more than 2 minutes, and the protocol will reduce the difficulty to get back to 2 minutes.Right now the difficulty is not for single miners, but for the network as a whole. There is no easy way to implement this idea, I am not sure adding name tags to this or that hash power would be a good thing, and it looks easy to bypass.
p.s: Thank you for no longer keeping to yourself, we are glad to have another voice to chat with, and this forum will grow thanks to that!
KabayaNerve (Monero dev) has made a github issue where people are invited to post their ideas. You can get more inspiration from there.Thanks for the welcome and for the time taken in your response, I posted a shortened version of this post on the github issue you linked to.
