Re: [bitcoin-dev] Selfish Mining Prevention

[Andrew <onelineproof@gmail.com>]

@ 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