Re: [Bitcoin-development] Auto-generated miner backbone

[Michael Gronager <gronager@ceptacle.com>]

"We propose a simple, backwards-compatible change to the Bitcoin
protocol to address this problem and raise the threshold. Specifically,
when a miner learns of competing branches of the same length, it should
propagate all of them, and choose which one to mine on uniformly at random."

So only in the case of two competing chains... The "Selfish Miner" today
has an advantage knowing which chain the other will work on, and by
simply choosing the other they get their advantage making it likely that
it is the other that will waste their effort. By using the random scheme
this advantage is gone.

Note again that it is only in the case of two competing chains, which
will happen on average every 60 blocks. So it is only roughly once every
60 block that you change from choosing one chain to doing a 50% random.

A rough calculation on earnings will be that you loose roughly 1/(2*60)
~ 1% of your blocks using this scheme. But at the same time you make it
harder for such an attack to happen. (This number might be slightly
higher, as working in parallel on both chains will make the two chains
last longer, so agree that we need a bit more analysis...)

I also agree that it is a kind of a Sybil attack, but I think we should
accept the risk of a Sybil attack but of course minimize it, rather than
introducing various social network (ip addresses) solutions, which in
one way or the other always have some central auth / oracle assumption.



On 4/11/13, 13:03 , Mike Hearn wrote:
>     The suggested change is actually very simple (minutes of coding) and
>     elegant and addresses precisely the identified problem.
> 
> 
> Disagree. Unless I'm misunderstanding what they propose, their suggested
> change would mean anyone could broadcast a newly discovered block at any
> point and have a 50% chance of being the winner. That is a fundamental
> change to the dynamics of how Bitcoin works that would require careful
> thought and study.
> 
> Also, their solution doesn't really address the problem they bring up,
> it just changes the size of the threshold required. 
> 
> Fundamentally, their attack is a sybil attack. It doesn't work if they
> can't delay or block a pools competitors because mostly their block will
> come in second place and they'll lose the race. Thus the solution should
> be a solution to sybil attacks.