The 1 PH/s user is either having major issues, or has left the pool (haven't been able to identify their speed on a pool that gives public user stats).

I don't think that should be taken literally, unless anyone with a batch one order has seen there's change to in progress, shipping, or shipped etc I wouldn't class it as being "in progress"

That's what wizkid is doing on Eligius, if you mined there, you'd get paid for the shares that were shelved during that time frame until wizkid has paid out 225 BTC worth of shares.  Obiviously that doesn't apply here as this is BTC Guild.  Not sure what, if anything, eleuthria plans or can do?  I know someone said they wouldn't call it theft, but I don't know what else you would call it.  The miner got paid for shares that were worthless because their hardware/software had an error that prevented them from submitting solved blocks.  So they got paid, but could never actually contribute since there was a bug preventing it.  Intentionally or unintentionally, it's still theft.  It's kinda like shopping and putting something on the bottom of the shopping cart, but forgetting to pay for it on the way out.  If you don't return the item or pay for it when you notice, it's still theft.

It was bad luck earlier this week.  But who knows, maybe yet another user is attacking (it isn't the previous withholders).  You can read above for why it's impossible to detect an attack unless it is sustained for long enough time to provide statistical anomalies for users.  But the bad luck spike we had lasted only a few days, and was caused by just a few very poor rounds.  The pattern does not fit an attack because we'd have a few normal length rounds, then one or two bad rounds, and then back to normal.  There weren't any significant speed fluctuations between those changes.

Eligius was able to hold 200 BTC hostage because Eligius does not pay out regularly.  BTC Guild pays out multiple times per hour.  Even if I froze the user's accounts, you'd get maybe a dozen, two dozen coins.  In return, you'd end up with some very pissed off people who already know how to weaponize their ASICs against a pool by simply reverting a patch.

Regarding the hard fork to make block withholding impossible:  It will never happen.  AFAIK, that hard fork would also break all existing ASICs.

Granted, a hard fork does NOT need 51% mining power to be implemented.  What matters with a hard fork is the market (people who accept/trade Bitcoin) moves to the new fork.  But unless I'm mistaken, the secret data used to prevent block withholding would be incompatible with all existing mining hardware, which will immediately make such a fork very hard to achieve.  It would more likely kill BTC entirely due to the competing standards.



As for variance/luck/withholding:  I'm monitoring closely users with bad share/block ratios.  Unfortunately, there's really not much else I can do.  It was around June 9th we had a pretty big dive.  But then we had a decent rise that roughly offset it before going into 3 days of consecutive very poor luck, caused mostly be a few 5 and 6 hour rounds.  However, the pool was at 96.8% luck for the last month before the dive, and rising.  99% is "neutral" in the sense of expectation, since you would expect a ~1% orphan rate which means 100% is actually slightly lucky.

The pool has not grown significantly, nor has the difficulty risen in the last 3 days.  The current dip appears to be luck, not withholding, based on the fact that the long rounds mean all the prior speed (11-12 PH/s), which was performing right within expectation for most the last month, weren't finding blocks for 5-6 hours along with the new speed that joined.

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.

If there was any actual downtime expected, a 24h+ window would have been provided.  For properly working miner configurations/hardware, the restart was virtually transparent.

The stratum servers will be getting restarted in 30 minutes (12:30 PM, PST) in order to deploy a fix.  bfgminer 4.1+ added TLS to Stratum as the default even though it was never a part of the protocol, and this ended up causing connections to hang for 1 minute+ when trying to connect to BTC Guild, and sometimes simply failing entirely.

The restart will only take a second to complete, but check your miners if they stop working, since historically there have always been certain miners which can't handle a disconnect properly.


EDIT/UPDATE:  Restart completed, everything appears to be working as expected.

Dunno. How much would you sell the S1 coupons for?

But your unkindness has scared me off.

I will be laughing when your coupons expire.

ok - so S2 landed about two hours ago
happy to report all cards were as they should be - reseated them all regardless, checked all the conections, all seemed ok
PSU does not look new - VERY dusty
Fired it up: ok
opened browser -> 192.168.1.99: ok
changed pools and IP to my subnet:ok
LCD:ok
restarted: Not hashing
checked all the cables, reseated BBB: all ok.
So now its up and on, but not hashing.
Tried a couple of pools: no change
Switched it from a static IP to DHCP: no change
tried /etc/init.d/cgminer.sh start & /etc/init.d/cgminer.sh restart


Would be most grateful if anyone could anyone give me some pointers on what I need to do to coax it into action?

Also: may not be relevant: but version of cgminer is blank in the 'System/Overview page

edit:for those interested: VAT into Ireland with UPS was €246.43

edit: the logins differ for the different interfaces as follows:
       SSH u:root p:admin
       Browser u:root p:root

thanks a bunch.  that got my first one hashing away.  that change plus reseating all boards and cables is prolly required for most to get them running.

well.. with the 192.168.1.1 line in /etc/init.d/cgminer.sh fixed
doing a:

/etc/init.d/cgminer.sh start

gets me mining...

still no display tho..  I'm thinking one of the other scripts needs to run to update the display..

Many times by several folks in here. Go open an account with a bank who has a swiftcode, no way around it.
Several of us, including myself, had to.

what is default IP as shipped?

Ok so KnC just turned from white to grey for me. While i don't care so much about the Neptune delay, what i care is that they are building a big datacenter in order to cover all Neptune Batch 1 customers in case of delay. That means at least 3Th/s * 1200 units=3600 Th/s just for them (yes they will hash for Batch 1 customers but only in case of a delay and just for a limited amount of time). That 3600Th is more than the promissed 5% (maybe it will be 5% after they ship the Neptunes, but until then it's just greed).

Instead of selling 1-2 Jupiters to previous customers they go their own way and keep all Jupiters for them. Avalon did it, Bitfury did it, BFL did it. The dark side is too powerful in the Bitcoin world.

they took all their 28nm production towards neptune and cloudhashing and drank jupiter owners milkshake