Shifts were bumped from 7b to 7.5b when the speed went back up, so it's now ~9.4 blocks for neutral luck instead of ~8.75.  Of course that'll change with the next diff change in about 8 hours .

And another small update to make sure the luck recording doesn't clip a shift with a block pending confirmation.  It probably hasn't happened before, but would've just now.  The entire network hasn't found a block in 50 minutes, and we solved our last block right before a shift close.

Very minor cosmetic update to the PPLNS Stats page.  The graph will now always use either the 2nd or 3rd most recently closed shift as the end point.  Ever since it was changed from hourly plot points to 3-hour average plot points, it was tending to be 4-5 hours behind the most recently closed shift.  It won't end on the most recently closed shift just in case there is a block pending confirmation that has not yet been credited to the shift (since the luck chart does not include orphans).

Wait, it happened AGAIN?  I only peek at the thread once in a while, but I always assumed people were still talking about the first time.

PPLNS is a time-delayed method.  Whenever a block is solved, the payment is applied to the 10 open shifts.  A shift takes ~1 hour to complete, so this means each block is split based on the mining activity of users over the last 10 hours.  So while your machines were offline, you were continuing to get paid for most of that time (though it shrank as new shifts completed where you had no shares).

When you first started up again, you wouldn't have any shares in the open shifts.  It takes a while to rebuild shares in all shifts.  This is the "charge up" period, and when you stop mining it's the "wind down" period.  They're symmetrical, meaning you aren't making more or less depending on frequency of mining.  Each share's payout is completely independent of future and past mining activity.  This is explained in the Support/How Am I Rewarded section.

Ignore it.  In no implementation of stratum will you see the response identified on that page with mining.set_difficulty and a weird hex string after it mixed with the subscribe response.  You'll see the mining.notify/ae6812..../extranonce1/extranonce2 size.

https://www.btcguild.com/new_protocol.php

At least a significant portion of the recent bad luck streak was already traced to a group of users that are developing their own ASICs, currently at ~1.8 PH/s.  They had previously mined on Eligius back in March and had solved blocks back then.  They moved to BTC Guild in early April, after difficulty crossed 4.2b.  They were not 1.8 PH/s at the start, they slowly grew over time.

We've since identified that their software was having problems at diff > uint32 maximum value (~4.2b).  They patched their software and went to Eligius to test the fix.  They solved a few blocks.  They had their accounts unfrozen on BTC Guild, and have since found a number of blocks in the last 24 hours for BTC Guild as well.

This being the Bitcoin community, most people are going to assume malice forever, even though these users got back to me immediately after their accounts were frozen when they could've easily proxied their miners and split them up more to make it impossible to trace.  They fixed the issue, and have since been reporting block solves as expected.

It's been pushed back a little bit due to illness.  It will be announced clearly on the website when it happens.

p2pool is just as vulnerable to withholding.  Maybe even moreso, since you can't actually take actions (ban/freeze accounts) against somebody doing it.

The miner would know enough to know how many shares they submitted.  They would not know enough to know if they solved a block though.

The other question of course:  Would that proposed solution even work with existing ASICs, since you're changing the block header fields that are going to be hashed?  Not that it matters...nobody is going to hard fork bitcoin in order to preserve pools.

We didn't luckily.  The N value is currently at just under 9x diff.  I can only recall 2 blocks in the last 3 years that were worse than that on BTC Guild, 1 block on Slush, and 1 block on Deepbit.

I reset the stats on the accounts that were frozen, because they've fixed the issue (confirmed solved blocks on Eligius with the same wallet as their Guild account).  I want to make sure I can accurately gauge their shares vs block solves.  Their accounts are disabled from receiving any payouts at the moment.

Kinda screwed up the pool speed calculation, trying to tweak that.

Before anybody says it:  No, they are not mining on the pool right now.  We're just stuck on a block at the moment.  ~5x current diff in shares submitted since the last solve.

Capped Pay Per Share with Recent Backpay.

What kind of bitcoiner are you?  Don't you know that in these parts, everybody is all pro-anonymity...until you don't like them, in which case it's only reasonable to demand that a user's information be given out publicly to an angry mob?

Unfortunately proving "without any malice" is similar to proving a negative.  But all signs point to it NOT being malicious, given the user has been in communication with me.  Only issue is time zones so there's long gaps in communications.  If it was malicious, they'd have no reason to get in touch with me.  A malicious user of that size would already have known they were hurting themselves financially by doing the attack.  Resuming the attack with proxies and new accounts would be a drop in the bucket compared to the income they were sacrificing already.

It's more due to the mass adoption of multicoin profit switching.  There simply aren't as many exploitable coins to make a profit off of anymore.

If they came back and mined for 1 month while not taking any payment from the pool, it would not make up for the difference (unless they were lucky or network diff suddenly got cut in half), since the difficulty is now higher than the month they started.  If they come back and add 10-15% to the pool's hash rate, and add 10-15% to the pool's blocks, that doesn't actually give anybody more money.  The slice they take out of each shift's payments would be roughly equal to the percentage of blocks they add to the pool.  That's a push.

Not correct.  Even if they come back and find blocks, that doesn't make up for the lost income from the month they were mining.  I'm still waiting for a response to my last email.  While I'd love to see them return some/all of the coins they mined in the last month and then work out a re-distribution for those shifts (recalculate the shifts with their shares excluded), past experience with payout errors (0.8 fucking up the backend and crediting miners as if network diff was from 2009 and costing me 1200 BTC for example) have made me fairly jaded when it comes to that.

Of course, Minor Miner's numbers are also completely wrong since he's using a 3 month luck figure when we know for a fact that the only confirmed "bad miners" were only around for 1 month.  Similarly, the assumption is that the pool luck would have been, at least, neutral without their influence, which is an assumption that has no basis.

It's actually not a net gain, it's a push.  The gain is your variance decreases, but that doesn't mean you make more (or less).