@ Eric: Yes I forgot to mention that cost (in addition to price) also determines the profitability of mining and thus the total hashpower. I disagree with your assessment of merge mining as really what matters is opportunity cost of honestly mining vs attacking, and one reason we are currently safe from other networks attacking is that SHA256 is ASIC friendly and currently the main network utilising this (the ASICs) is Bitcoin mining. It would be hard for people computing prime numbers to quickly switch to Bitcoin mining, since they would need the ASICs. But if you really want to discuss this then I suggest opening a new thread here or bitcointalk since this is off-topic from my thread. Also there is a discussion about merge mining here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-January/003981.html
On Mon, Sep 17, 2018 at 2:09 PM, Zawy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > The 51% problem is deep. Any discussion of a solution to it should > begin with a link to an article that shows a profound discovery has > been made. Selfish mining prevention and pollution should be on > bitcoin-discussion, but it appears that list is not active. > > The problem with Andrew's idea below is that it is a positive feedback > loop that amplifies oscillations. If h goes up or down due to price > changes or random solvetime variation, then the net reward goes in the > same direction, which motivates miners to cause h to go even further > in the same direction, which is a positive feedback loop until some > limit is reached. To make matters worse, miner profit motivation in > choosing which coin to mine is a non-linear function: a 30% drop in > difficulty (or 30% increase in this reward function) in an alt coin > can cause a 300% increase in hashrate. > > Average of 144 past blocks to determine h are needed so that it does > not vary too much. A selfish mine of 72 blocks would result in only a > 12.5% loss compared to not using this pro-oscillation function. I've > tried similar reward functions in trying to reduce on-off mining. > > There may also be a problem of issuing too many or too few coins, > depending on how fast h rises in the long term. > > An alternative is to increase difficulty with this or a similar > function instead of reward. From a miner's perspective, there is not a > difference (they are only interested in the (price+fees)/difficulty > ratio. This would have the same problems. @Zawy: Are you talking about my proposal to modulate the subsidies? Because if you read my second post you see that I scrapped that part as it can be disruptive, and I am only proposing to let users have more control over how their fees are spent. A certain portion of fees is put in reserve and gets allocated to miners based on hashrate conditions, and once the "contract" expires, the remaining part goes back to the user for future fee payments. I understand it is unclear whether this will cause a significant benefit (I can work on simulations if I have time), but what could possibly go wrong with giving users more choice over how their fees are spent? Also if you see my post, I am not just trying to prevent Selfish Mining (33%) or 51% attacks, but in general any types of attacks that try to drive away mining competition (like block withholding attacks, networking attacks, etc). Someone on bitcointalk was also worried about a positive feedback loop, and I think my answer remains valid: "First, I think a price drop will be slightly offset by the lower rate of coins being mined. Also, confirmation times will get longer: Both the time to get a block will increase and the number of confirmations needed to have enough work done on the chain so that your transaction is considered safe. The fees would likely rise and this would increase rewards to miners, especially in a fee-market dominated future." Merge mining can also help to smooth hashrate so it doesn't depend so much on price, but even without merge mining it is not so clear that a there would be a destructive feedback loop and that's where simulations / math equations would help. Your idea of increasing difficulty, I haven't thought about much, but I don't think it's the same effect. When you increase the difficulty, the reward per block remains the same, only reward per real time falls, but it could also have the negative effect of incentivizing selfish mining or timestamp attacks to reverse the increased difficulty. Though actually timestamp attacks would sort of be dis-incentivized if underestimates of hashrate led to lower rewards. Obviously I will not work on a pull request if there is no strong interest for this. I think it is a harmless addition, so if I have time I can work on simulations to try to prove that there is a significant benefit with doing this. -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev