(Talking about the paper, not the BIP). With regard to racing the other winner which catches up when private pool length=1:
i) the model does not appear to take into account that when another pool goes on to mine a block, and the attacker publishes their selfishly-withheld block, the selfish pool will not be able to change the existing winners mind. This is not insignificant as the pools have 30%, 20%, 15%, 7% etc. ii) The miners already have an incentive, as other big bitcoin processors, to maintain fast, secure and redundant links to other significant miners. The attacker is giving up a large proportion of their winnings from the times that they win at all. Say the attacker IS the 30% pool, when he wins and waits for someone else to win, > 80% of the network is pool mined, so there is a good chance that the other winner individually represents a non-negligible proportion of the network or a sufficiently well connected portion of the network that the attacker will be unable to race them to publication with a useful proportion of the network. iii) Also broadcast is not instantaneous, lets say network propagation takes 10 seconds; a big proportion of the time, the actual mining times will be more than 5 seconds apart so that by the time the selfish miner learns of the block, much of the network will already have accepted it block as first. iv) Even within the 10 seconds ambiguity period, the more powerful miner will tend statistically to come first, and so reach a bigger portion of the network, as well as having a stronger incentive to maintain links as in ii). These four factors erode the achievable \gamma parameter. I suspect it unlikely \gamma>0.5 would be achievable, putting the profitable threshold \alpha in 25% - 33%. (And assuming whatever techniques to reduce latency are used by the selfish pools can be used by other pools.) Your main result that even with \gamma=0 (if you dont win any races) that you still win once the selfish pool reaches 33% is an important new indication, which needs further consideration. (And you could expect to win some percentage \gamma>0 even with the factors I mention, and full implementation of the same latency reduction techniques in all moderate sized miners, selfish and normal). It is also not clear what will happen if multiple selfish miners compete with each other. A selfish miner cooperating as a peer to increase percentage runs risk of mutual sabotage - he has to announce his private block to his co-conspirator, and the co-conspirator may publish, or collude with another non-selfish miner. Your supposition is there is a profit motive to collude. However there are other profit motives in bitcoin that are not exercised - for example there were for sometime 2 pools that had excess of 50% power, and yet this was not abused for double spending. Of course increasing profit by a new mining strategy is not theft as double spending which has a clear loser. Miners even exercised restraint and volutarily avoided growing over 50%. As others have I think said by now analysis is welcome. It seems that Peter Todd may have observed the same or something similar wrt miner incentives some months ago, though it wasnt as widely read nor formally verified. It might be useful to release the source for your simulator if that is open to you. In my opinion a constructive direction for reducing centralization risks is to try to reduce the use of and motivation for pools. Even at <51% per pool there is (probabilistic) miner risk in double-spends. And there is risk that the large miners evolve to become a defacto policy enforcement point for policies not aligned with user interests, or with fungibility of bitcoin which itself presents another kind of risk (defacto reduced fungibility should this arise would also be bad for bitcoin). Also without even having mining power, there is scope to network hacking (eg of routers in front of miners) to influence the mining profit, and even double spend. As I mentioned large miners have an incentive to maintain secure redudant links (probably some links using Tor for blocks) as a counter-measure. Adam On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote: > Hello, > Please see below our BIP for raising the selfish mining threshold. > Looking forward to your comments. ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
