International Sales are now available on the ASIC Store page!


UPDATE:  Requests to lie on the customs declaration will be ignored.  I will not be a party to your attempt to evade taxes/duties by falsifying the information on the form.  Amounts will be declared using approximate wholesale values, denominated in USD.

@ eleuthria: idk if its bugged, but my shares from shift 8355 to present are not being displayed, yet my activity keeps showing accepted work every few seconds. pm me for more details plz

Edit: no change after restarting miner, just to make sure miner wasnt bugged.

Thanks Eleuthria,  Good to hear. 

I know the store went live and a coupon redemption program was never thought to be a remote possibility.

Looking forward to those "Golden" Coupons to the ASIC factory.     

Use cgminer and my API
Write a little script to check it every 2 seconds for expected values.
The most useful one being 'devs' "Last Valid Work"
There are sample programs to access the API in Java, PHP, Python and C
Clicky: API-README

Unfortunately, anything related to a worker's actual speed will need to be a local warning system.  It's much more reliable, and more feasible to implement.  Some kind of API monitor that sends you an email when a worker drops too low would not be hard to implement, whereas offering it as a standard feature could add a lot of extra load to the pool given how many actual workers are running at any given time.

It's something I'll consider.  If it's a big annoyance, one current workaround is hiding that worker.  Hidden workers will not generate idle notification emails.  Idle miner code is something I have been meaning to rewrite the script for to find a more efficient way to scan through the last share times of workers, so once I get to that (right now my focus is DDoS mitigation + new colocation), I will likely fit in the per-worker notification settings.

I'm splitting my time efficiently.  Working on shipping gives me time to think about additional precautions and sanity checks like I posted earlier.

Shipping Update:  I've done ~40 packages so far, and expect to get quite a few more done before they ship out.  Please note that the Shipping Queue is an absolute number, increasing by 1 per order.  Most orders in the queue beyond 100 are going to go MUCH faster.  The earliest orders contained large quantities per order, while later orders tended to be much smaller in size.

Yes, Manual payouts are still disabled at this time.  An update now that I've had a day to work on it:

Yesterday, a significant number of coins were stolen from the pool.  The exact method this was done is not yet known.  Most of my time yesterday was spent doing a full audit on all SQL queries and RPC calls.  No immediate issues were apparent, so a full rewrite was done on significant amounts of code, including a full overhaul on frontend interface with the backend.  The frontend is no longer responsible for any payout calls, nor is it capable of editing/deleting/inserting information into the database related to earnings or payouts.  Additionally, the frontend is no longer capable of making RPC calls to the backend at all.

This is why manual payouts are still currently disabled.  At this time, the frontend is not capable of making modifications to payouts, or sending payouts.  I'm working on a new process to get manual payouts working again soon.  It's currently a 2nd priority, as I'm falling very far behind on packing & testing of erupters.  Going to be spending the first half of today getting 1/3 of the units shipped, while I think about all the double checks, sanity checks, etc., that will be needed in order to restore manual payouts in the new system.

Longstanding bug on windows for when network goes down; it's my secret way to get people to move to linux.

Obviously not the case, but anyway I've not been able to reproduce it myself so must be some combination of windows or other issue. You could always try helping debug it following instructions in here:
http://ck.kolivas.org/apps/cgminer/debug/

I suspect it's just the libcurl implementation on windows... which would be bad news since it won't be something I can personally fix.

I think there's still something awry with gracefully handling disconnects.  It isn't unique to stratum, as I've seen it on LPs as well.

Right now have three units running... one with 1 GPU, one with 2 GPUs, and one with 3 GPUs.  At the time all were pointed to stratum pools with bitcoind (LP) as a backup.

My internet connection dropped for a short bit.  The 1GPU machine recovered properly.  The 2GPU crashed, the 3GPU hung.

I've seen this before, where those with multiple GPUs crash or hang when the 1GPU continues working.  The 1 and 3 GPU machines are window 7 x64, the 2 GPU is windows 8 x64.

Using 2.9.6.

M

No, it is plain TCP socket.


Make tunnel from localhost:3333 to stratum.bitcoin.cz:3333 (yes, this one, really) and point cgminer to "stratum+tcp://localhost:3333".