Nicholas Weaver is reporting that pools have already started delaying blocks, something that hints at Selfish Mining, since Nov. 3rd. https://medium.com/something-like-falling/d321a2ef9317 He dismisses other reasons for delayed block propagation. Any ideas on whether pools are already mucking around with block delaying tactics? I have no idea if this report is accurate or explained by some other issue in the network, does anyone here have a comment on this? On Thu, Nov 7, 2013 at 10:28 AM, Daniel Lidstrom wrote: > Hey Peter, something seems wrong with your above analysis: I think a miner > would withhold his block not because it leads to a greater probability of > winning the next one, but because it increases his expected revenue. > > Suppose a cabal with fraction q of the total hashing power is n blocks > ahead on a secret branch of that has mined r_tot coins, and let r_next be > its next block's reward. If the cabal chooses not to broadcast its secret > chain until at least the next block, its expected revenue after the next > block is found is > > (1 - (1-q)^(n+1))*(r_tot + r_next) > > If it does broadcast, its expected revenue after the next block is found is > > r_tot + q * r_next > > If the cabal seeks only to maximize immediate revenue, then after a bit of > algebra we find that it will withhold its chain if > > q > 1 - ( 1 + r_tot / r_next )^(-1/n) > > So if the cabal has just mined his first block off of the public chain, > i.e. n = 1, and if the block reward is relatively stable, i.e. r_next = > r_tot, then it needs q > 50% to profitably withhold, not the 29.2% you > calculated. > > From this formula we can also see that if the miner wins the race and > withholds again, then he must grow q to compensate for the increase in > r_tot, and any decrease in n. So generally publication becomes > increasingly in the cabal's interest, and secret chains will tend not to > grow too large (intuition tells me that simulations using the above formula > should bear this out). > > This seem correct to you? > > > On Thu, Nov 7, 2013 at 9:14 AM, Mike Hearn wrote: > >> Once the ASIC race calms down because everyone has one, has more or less >> optimal power supplies, process improvements aren't easily reachable >> anymore etc then I'd expect people to dissipate from the large pools >> because eliminating their fees will become the next lowest hanging fruit to >> squeeze out extra profit. There's no particular reason we need only a >> handful of pools that control a major fraction of the hashpower. >> >> If we end up with a few hundred pools or lots of miners on p2pool, then a >> lot of these theoretical attacks become not very relevant (I don't think ID >> sacrifices will be so common or large as to justify a pile of custom mining >> code+strategies at any point ...) >> >> >> On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd wrote: >> >>> On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote: >>> > > P.S: If any large pools want to try this stuff out, give me a shout. >>> You >>> > > have my PGP key - confidentiality assured. >>> > > >>> > >>> > If I find out one of the large pools decides to run this 'experiment' >>> on >>> > the main network, I will make it my mission to tell people to switch >>> to a >>> > more responsible pool. >>> >>> I hope they listen. >>> >>> A few months ago ASICMiner could have made use of that attack if my >>> memories of their peak hashing power were correct. They certainely could >>> have used the selfish miner version, (we need better name for that) >>> although development costs would eat into profits. >>> >>> GHash.IO, 22%, says they're a "private Bitfury ASIC mining pool" - dunno >>> what they mean by that, but they're involved with CEX.IO who has >>> physical control of a bunch of hashing power so I guess that means their >>> model is like ASICMiners. They're a bit short of 30%, but maybe some >>> behind-the-scenes deals would fix that, and/or lowering the barrier with >>> reactive block publishing. (a better name) >>> >>> > And if you think you can get away with driving up EVERYBODY's orphan >>> rate >>> > without anybody noticing, you should think again. >>> >>> ...and remember, if you only do the attack a little bit, you still can >>> earn more profit, and only drive up the orphan rate a little bit. So who >>> knows, maybe the orphans are real, or maybe they're an attack? ASICMiner >>> was involved with a bunch of orphans a while back... >>> >>> You know what this calls for? A witchhunt! >>> >>> BURN THE LARGE POOLS! >>> >>> > > P.P.S: If you're mining on a pool with more than, like, 1% hashing >>> > > power, do the math on varience... Seriously, stop it and go mine on a >>> > > smaller pool, or better yet, p2pool. >>> > > >>> > >>> > That I agree with. >>> >>> Glad to hear. >>> >>> -- >>> 'peter'[:-1]@petertodd.org >>> 0000000000000007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112 >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > > ------------------------------------------------------------------------------ > 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 > >