The NEO has both USB and NFC interface.
You can use Yubico Authenticator desktop version (Windows/Mac/Linux) or the Android app.
Both time-based (TOTP) and event-based (HOTP) are supported, but since all Yubikeys including NEO has no clock on it,
Yubico Authenticator has to send time data to the Yubikey in order to get TOTP back.

The translations in 0.9.0 release is not the latest on Transifex.
I don't understand why the release team don't pull the latest into the release,
especially some strings are just replaced/updated several weeks before the release.
It annoys me as a translator because it happens several times, and I see half-baked translations in a release.
It could be better that the release schedule includes a period to call for translations,
so developers have a deadline to update strings to be localized,
and translators have a deadline to finish their work.

I confirm that I received full refund from soniq in December.

Thanks for the delivery, Marto.
The fans are really noisy, I replace them with low CFM and quiet ones,
and run the HEX8A1 with only 175 in frequency and 870 in voltage parameter.

When connected to Linux machine, lsusb will show:
Bus 001 Device 017: ID 04d8:000a Microchip Technology, Inc. CDC RS-232 Emulation Demo

And it appears as a tty device:
crw-rw---- 1 root dialout 166, 1 2g  16 08:51 /dev/ttyACM2

Showed in dmesg:
[  161.103406] cdc_acm 1-1.1:1.0: This device cannot do calls on its own. It is not a modem.
[  161.103442] cdc_acm 1-1.1:1.0: ttyACM2: USB ACM device

Running with cgminer:

While I also run bfgminer with other mining hardware, it seems bfgminer could cause the OS to hang when it probe the tty device.
This can be avoided with run HEX8A1's cgminer first (so the tty device would disappear), or plug the HEX8A1 after bfgminer runs.

Oh, and it runs well with p2pool, with less than 2% DOA, compared to 5~6% DOA for BFL or BitFury devices.

 
Sometimes (ex. when payout queue is very long) wizkid057 would make manual payout with normal transaction,
it is not unusual.

I agree with you except the port number in your signature

I just tried it for nearly 2 days with 33Gh/s,
20min miner hash rate floats between 25 to 38Ghz/s, I guess it is due to high difficulty (256).
Reject rate is about 1.2%, and pool statistics from bfgminer:
I think this pool could be considered stable.


Look forward to your report for next week

Hope you have progress with it, organofcorti.
I tried the pool for some time, and observe the following:
1. The pool always gives out works of difficulty 256, no matter with 333Mh/s or 33Gh/s hardware;
2. No pool statistics is available even for a registered user. I can only see user hashrate graph, miner hashrate, balance, etc.;
3. Payout is round to 0.0001, the remaining is kept in user balance.


Regards,
iongchun

Of course not, you can read from my signature

From what I read on f2pool’s website, it is a PPS pool with 4% fee (24 BTC paid per block),
payout is made once a day for miners with balance of 0.0005 BTC or more.
It seems only Stratum is supported as mining protocol.
I guess tx fee is kept by the pool.

Discus Fish is the pool operator’s nickname, his/her pool is f2pool.com
Pity that no much public data can be found there for unregistered user.

I don't want to convince you, because we value the benefit of mining differently.
Especially the decentralization and variance part.

You could think in p2pool way.
If your good share rate is higher/lower than others in p2pool,
your average income is higher/lower than others in non-p2pool.
Then take low miner fee, tx fee, p2p, and coinbase tx as pros, and higher variance as cons.

This can be done easily, but such a "big pool" feature might not be suitable for p2ool,
I guess it is why forrestv does not implement or hear the request.

You could try --miner-share-rate or --address-share-rate in auto-worker-diff branch of my git fork:
https://github.com/iongchun/p2pool.git

Hi Luke, thanks for the driver, just tried the latest code with my Drillbits, I have 2 issues:

1. Stats is unavailable for thumbs, so bfgminer causes lots of "Short read in response to 'T'" error.
Just adding a "if (dev->procs == 1) return false;" in drillbit_get_stats fixes this for me;

2. The range for external clock should be wider, many people overclock Thumbs to higher than 230.
Currently cgminer driver do not limit it, just prints a warning when lower than 80 or higher than 230.
Angus of Drillbit Systems had suggested to try 250 for up to 3GH/s with active cooling and enough power (1000mA).

I can only say, what we enter is correct address (postal codes) for any other delivery services, even  for UPS itself.
The problem is in the UPS validation API, either you use it in a wrong way,
or the data on the server is plain wrong or incomplete.

I suppose you mean the difficulty for each worker, since it reads like node-basis (i.e with your miners...).
Actually everyone can adjust this by append the number they want to the username (address or not),
for example, 13qnEgPTxJW6mm88dLpnHXZyryN5EXBciq+16
But I think it just make the graphs looks nicer for small miners 

Running v0.1.10 firmware for more than 3 days with Eligius and HHTT:
"Response from pool too long" only occured once with Eligius, and S-HASH switched to HHTT after some pool rejections.
After some time it switched back, and kept working with Eligius again smoothly.
Thanks cscape for  the new firmware!

I see... no wonder NanoFuries and Drillbit miners also have high dead rate (about 6%), like BFL miners.
But the situation of these Bitfury miners is still better than average dead rate (6.7% in month) of p2pool network.
Maybe because it is a common issue for mining hardwares, though with different causes.

I see, then there is little hope for the S-HASH to work with P2pool.
Currently I will stick with Eligius but fallback to HHTT to see how it works.
Thanks for the help!

"Response from pool too long" problem also sometimes happens with Eligius,
I guess it is due to large generation transactions for payout?