Since you're not mining here and are not supporting the pool, please stop trolling this thread with your nonsense.

-wk

Maybe the Mail with the tracking numbers are stuck in (customs)proxy  

WinTame2012, ну с погодой ещё не ясно, не сейчас же ехать...

Huh?

Default payout, 0.17219640 BTC total, and it says this:

CPPSRB is a good system.

There is nothing left to pay out on that address.  You're in queue for 0.16586020 BTC, which includes estimated payout for the current round/next block.  Although, it looks like you've removed the majority of your hash power, so, that will likely drop since you are no longer contributing and you're not adding as many shares and the current round is unlucky.  Under CPPSRB, constantly active miners will always end up with the best long term rewards.

Just a general note (to everyone, not just the person I'm replying to).  Please read the FAQ on the CPPSRB Reward System. Shelved shares are not ever owed by the pool in any way shape or form.  They are simply shares which were submitted, added to the share log, and have not yet had funds available to be paid (ie, luck).  Displaying Shelved Shares as a value in BTC turned out to be a mistake since too many people either assumed that they should be getting rewarded that amount, or would rage quit when, even though their % paid was high, would misunderstand the system and think that reward system was broken for not paying them for shelved shares.  Displaying the % of shares rewarded so far is a much more useful metric than a value of shares not yet rewarded.

The pool does not owe shelved shares.  The pool will pay as many shelved shares as possible when it is possible with every lucky block.  But, if there are not sufficient funds mined to go far enough into the share log to pay everyone, then obviously they can not be paid yet and they will sit in the share log (shelved) until such time as they can be rewarded/paid.

-wk

There was a small glitch in the new custom minimum payout code that caused the reward system to pause as a fail safe.  I'm working on it now and letting it catch up with the shares database so I can get everyone paid.

No worries!

-wk

I think it is being held in customs.

Exactly same like B3 buyers - 2-3 months delay made our ROI pretty impossible.

+1
this issue of late batch #3 and impossible breaking even due to late delivery should also be adressed

ok. this is pretty stupid of me, and completely my fault.

the system is designed to move cold storage to hot wallet -> then send out refunds.

but apparently the move failed and the script tried to send a bunch of refunds while the input contained no coins...

1000 coins have been moved and script resumed, I'm sure people should see refunds instantly and can vouch. and once I get back on location I can enable more coins to be moved and thus refund resumed.

again, I apologize for the long delay.

Hi
After reciving waranity replacment, i`m trying to work with new unit.
Works well at low with ~10500Mhash, but when i`ll switch to High, it stops working at all, or close to it.
After few minutes, reboots. At low works well for 16h in a row.

Any adwise? should i check voltage or smth ??

That's right. It's not a solution.

If 50BTC is using a large coinbase, you might have been getting struck by the excessive CPU usage limitation in older firmware just like p2pool was. This might manifest as duplicate shares and only show up as rejects at your pool. Most of the recent updates were created to address precisely that problem. Try my latest firmware.

http://ck.kolivas.org/apps/cgminer/avalon/20130814/

No, that's not actually making it better unless there is an actual problem with the pool - which would mean don't use the pool.
Going from 8diff to 64diff simply means your Reject share variance increases.
Coz on average you find 1/8 of the rejected shares ... but they are worth 8 times as much each.