On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <jeremy@taplink.co> wrote:
 
I think it's a stretch to say 'y' is 0 with good connectivity. Even the best connected mining pools today are concerned with this 'y' factor. 

Check out the following paper for the effect a single node can have on propagation, and on the relation between block size and propagation speed. This strongly supports our assumption. 
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
 

Here's a probably very dumb idea... to throw out one possible "solution"...

You want a way to fake-out the 'selfish miner' into disclosing their blocks -- how can your force their hand to prevent them from accumulating longer private chains?

What if you propagate (and relay) an encrypted block header which honest miners will timestamp when they receive it, then 10 seconds later propagate the decryption key to unblind it. But here's the catch - maybe the decryption results in junk, maybe it results a new longer block. If it's a real block then it gets priority based on when the ciphertext was received instead of when the decryption key was received. Now 'selfish miner' can't race the network anymore, because they are always in state 0' and can't tell if they are up against a ghost, or a real competing block. If they wait for the decryption key to check, it's too late, and they are guaranteed to lose unless they can out-race the network, e.g. back at t=50%. Of course there would need to be some way to anti-DDoS this which allows for some amount of these fake-outs without letting them get out of hand.

That's a dangerous way to go, opening the door to DoS attacks, as you mention. Besides, it makes a simple algorithm complicated, and doing such changes may lead to different vulnerabilities that are difficult to cover. 

Best, 
Ittay