Good luck getting an auditor to accept it (and trying to claim a loss like that is a surefire audit flag).  Also, hope you aren't trying to deduct 750k based on market value in losses on coins you acquired at lower cost basis.

Don't get me wrong, in this case I don't think there is much threat of the "accidental 51%", or even much chance of any noticeable edge towards PetaMine, though there would be a very slight one.  It's just funny that like I posted earlier, how much of an advantage actually increases the worse their connectivity to p2pool is (assuming fully benign operators).

If Peta-Mine was an even larger portion of p2pool, it could become a problem.  You don't have to be malicious to get more than your fair share.  Just like with Bitcoin, there's an inherent advantage to being a larger share of the network (or larger share of p2pool in this case).  The bigger you are, the more likely you are to confirm your own block/share in an orphan race.

Ironically, this would also reward them for having a *worse* connection to the rest of the p2pool network, because they're more likely to cause orphan races that way, and they would have a better than 50% chance of winning the race each time.  It requires no effort or malicious intentions, it's simply how the system would work in that scenario.

I actually made this argument back in early 2013 when people kept screaming that ASICMINER (at the time > 25% of the entire BTC network) should use p2pool.  Had they done it, they would have likely performed an "accidental 51%" attack because of their poor latency (being based in China) and the fact that they would have completely dwarfed the rest of p2pool's hashrate at the time.


It wouldn't be quite as big of a problem these days since p2pool increased the average share time.  It's still a slight issue where somebody with a significant hash rate (> 50%) is able to get a little more than their fair share, but it would have been extremely bad if p2pool still used the 10-second target time for shares.

That's more likely your OTHER stats, like the fact that it seems to be getting a ton of HW errors.  Discards have NO effect.  It is a stat that shouldn't even be made visible anymore because I don't think there's a single pool out there still using getwork.

Discarded is a meaningless stat unless you're using getwork (and even then it only matters to the pool operator, not the miner).  It is a 100% useless stat on GBT and Stratum.  Discards are not rejects, they aren't even shares.  It means your software had work prepared to hash but instead it discarded it in favor of newer/fresher work.  You aren't wasting any  hashes when your miner discards work.

Java != JavaScript.  It would have no effect unless it really screwed something up with your browser.  Are you using Firefox by chance?  I know Firefox's javascript processing has been really spotty with different versions of the browser (it completely hanged on the PPLNS luck graph back before I started merging multiple shifts into a single datapoint).

The script that is hanging up for you is the one that paginates the data.  Every detail view loads the entire list, then javascript reduces it into the searchable/paginated table.  Sounds like you're interrupting the script, meaning it never paginates it, leaving a giant unsorted/unsearchable list instead.  It's not instant, but I've never had it take that long on any of my computers.  Even my phone is able to do it fairly quick.  But I use Chrome (and android/chrome on the phone), which is really fast with javascript.

The 200% PPS part didn't make sense to me from Luke-Jr's post.  Only the fact that they would earn a little under twice what they should earn if a 51% attack was done against p2pool's sharechain, assuming they had just over half.  But it's not a stealth attack, it would be noticeable before p2pool actually found a block (100% orphan/doa rates for all p2pool peers in the long run).

Nothing changed, we just got one hell of a burst of blocks.  5 between 7:30 and 8:23 (PST).

I'm unable to think of a way to fix this problem, it's essentially the same problem as Bitcoin itself has when it comes to a 51% attack.  If p2pool did something like limit the size of a sharechain re-org to only so many shares deep, it would work most of the time, but it would fail if there was ever any major communication issues between countries, essentially forking p2pool into multiple p2pools because they would refuse to come back to a consensus.

I've fixed the incorrect LTC exchange rate used on the dashboard for your approximate BTC earnings.  It broke after the removal of LOT&MEOW from the switching system.

p2pool is like a miniature Bitcoin blockchain.  If you had 51% of the p2pool hash rate, you could (more often than not) force your own shares into the sharechain instead of someone elses by forking it until your chain was longer.  I'm not sure what, if any, precautions are present in p2pool to prevent somebody from purposely forking the sharechain in their favor.

An "obvious" one would be making it so nodes ignore a forked chain more than 'X' shares deep, if it all pays out to the same address (indicating somebody forked from the chain to build a longer one that only pays themselves), though all that you'd have to do to combat that is cycle through addresses when making your fork.

In other words, p2pool users would be mining a block which pays almost the entire reward to the attacker, even though they've only done 51% of the actual work.

The pool will get MEOW blocks because some users insist on manually mining them.  The auto switcher does not touch MEOW.

At under 10% of the network, calling 2 weeks "midterm" is one hell of a stretch.

Do not use pools as a bank

Posting this reminder as once again a significant number of coins had built up in the hot wallet and have been transferred to the cold wallet.  Please do not use the pool as your bank.  The incoming coins to the pool should be almost exactly mirrored with withdrawals, with the exception of small balances unable to meet minimum/auto withdrawal levels.  When this doesn't happen, it forces the pool to move coins into cold wallets, and in the event of a sudden spike in withdrawals, can severely delay the availability of funds since they have to be moved back to the hot wallet.

Got it, so you're using extremely short term figures.  Good thing you didn't try BitMinter during their just-under 3 day long block, you might've had 0%!


90.275% 1-month luck
91.472% 3-month luck (which includes the 1 month where there was a proven block withholding attack, meaning it includes the worst month in the entire history of the pool)
98.137% luck since September 2013.

These are out of 99%, which would be the target assuming a 1% orphan rate.

Yep, it's been a month.  And those users have been the pool's top block solvers in the last month.  We're 8-9% under expected this month (again, 99% is expected after accounting for 1% orphans).  Our 3-month actually went up recently (apparently a bad spell from early April has rolled off the window).  Curious to see what it will be once the block withholder's effect is no longer a part of the 3-month average.

No, we're talking 90%.  Exaggerating just makes you look like an moron.

I've still never seen any math where a withholding attack doesn't cost you more than it provides.  If you have 10 PH/s, the network is 100 PH/s (including you), and you do a withholding attack on a pool with 20 PH/s.  Okay, so now you have effectively removed your 10 PH/s from the network, so the difficulty won't reflect your speed.  However, in the course of doing that (effectively reducing the next difficulty by 10%) you're taking a HUGE cut in your pay.  You'd be earning 33% less than expectation (you would be 1/3rd of that originally 20 PH/s pool, and by withholding that pool will under-perform by 33%).

I've played with the numbers endlessly, and the result is always the same.  You cannot perform a withholding attack where you end up earning more are higher than they would be if you were legitimately mining at 100% capacity.  It's the simple fact that you can not make the network difficulty be adjusted by more than the pay cut you're taking by performing the attack.

Now, this obviously only applies to non-PPS pools.  With PPS it's completely viable to do withholding attacks because your earnings hit is only the pool fee whether you are solving blocks or not.  Your only problem there is making sure you are able to continue pulling your balance out before the pool goes bankrupt.

Correct.  The current system will have eternally shelved shares (most likely) since the expected luck is 98-99% due to orphans.  Luck can pay off some shelved shares, but it's extremely unlikely it will ever pay them all.  The problem with paying oldest first is that it penalizes newer miners, which discourages pool growth, and instead of having very old shares that will never get paid, its the newest shelved shares that will never get paid.