Post
Topic
Board Development & Technical Discussion
Merits 3 from 1 user
Re: Solving Selfish/Colluding Mining
by
onelineproof
on 07/09/2018, 13:39:01 UTC
⭐ Merited by DarkStar_ (3)
@Heretic says:
Quote
If the mining reward is reduced with a drop in difficulty, Bitcoin becomes even less profitable to mine, with more and more miners leaving as block reward is further and further dynamically reduced, creating the very pool of "spare" hashing power that the difficulty-dependent-block-reward is trying to avert.
I want to revist this scenario, assuming no merge mining. 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. It would be nice to write this up in terms of mathematical equations to see exactly what would happen.

Anyway, I am proposing just to modulate the fees (not the fixed subsidy). I think a good way would be to let users choose how their fees are used. If a user wants, they can say: "I am paying f h/p to the miner", where f is the nominal fee, h the hashrate of the past period (current hashrate), p the peak hashrate. So the miner who mines the block with that transaction will only get f h/p, and f-fh/p will be kept in reserve and can slowly be released to miners as the hashrate approaches the peak. For example, if once the current 144 block period is over, it is calculated that h2 > h, then h2/p-h/p will be released to miners who mine the blocks in the next period (perhaps spread evenly over that period). Like this each user can choose more precisely how they want their fees spent, and it makes sense that they would care about the security provided by blocks coming after the transaction they make, instead of just caring about the immediate block they get their transaction on.

Can this sort of thing be done easily with a soft fork or some kind of smart contract between users and miners? I don't know, I am thinking about it.

@Heretic says:
Quote
Anyone willing to waste their resources on mounting a 51% attack on Bitcoin will do so regardless of whether we try to tweak the incentive structure in one way or another. Assuming such an adversary exists, selfish mining or covertly aggregating (unused) reserve hashing power would be the least of our worries.
Also revisiting this...I think I should add another category of attacks that I am trying to prevent: subtle attacks that are profitable and don't significantly affect the price of Bitcoin. This could be block withholding attacks (mining pools wasting each other's resources), networking attacks (to mess with other miners' connectivity), physical attacks (like purposely selling defective hardware and for yourself mining with the good hardware). I think this is what Peter Todd was talking about in the Reddit post about "other subtle and more effective attacks", and he (and others) likely don't want to lay them all out to give attackers bad ideas. Even EMP attacks on general electric devices can be considered "subtle" as it can be done to look like just an attack on general devices, while really it is targetting an area dense with honest miners. The selfish mining attacks and collusion attacks (the other categories) can also be done quite profitably I think, but with Internet anonymity still immature, they are less practical (as Peter Todd also indicated). In general, the point of my proposal is to disincentivize miners from driving out the competition. With the same reward for a lower hashrate, it is profitable to drive out competiton (lower overall hashrate) as that gives a bigger share to the attacker, and the same reward. If someone knows other ways to achieve this goal, then please let me know. This is one simple way that I think would work.