Version 0.4 released!

https://github.com/colinrgodsey/scalaminer/tree/v0.4

* Stratum connection pooling with priority and weight
* BitFury support (Nanofury and Blue/RedFury)
* Various stability and performance fixes
* More accurate timeouts and identity failure

https://github.com/colinrgodsey/scalaminer/compare/v0.2...v0.4

the next version of ScalaMiner (0.3) will have out-of-the-box remoting support. I've been using it for remote development and developing with miners that dont seem to get along with OSX (remote linux machine).

I'm curious what your use case is with this?

I'll see if i can make a table. I finally tested that code and it should work (will verify against some actual data), can probably just make a script to dump it out to CSV quick.... can throw that into excel or whatnot.

just blew my corsair 500 =\ I thought I was passed this. But Im also running 1 blade and 2 gridseeds with it... that was probably my downfall. upgrading to a 750

ahh, right. so 'bits' is the actual blockchain difficulty at the time- its stored in the header as a coherency mechanism for difficulty across the network (blocks calculated with an old or otherwise badly computed difficulty)

when working with stratum though, we dont really care about the network difficulty, because that's all the pool's dealings.

Pooled mining is basically based around overriding the network difficulty. if we didnt have pools, we'd all have to use the network difficulty and would have massive variance in our hashing power. So what pools do is make you work on a much lower difficulty so that you can prove to the pool that you are infact mining, and they can calculate from that the number of shares you produced and how many shares it would take on average to calculate a block (basically).

So basically they're just computing how many 'hashes' you've guessed in that round (theres a formula for how many hashes on average an x difficulty share would take to guess), and how many hashes were computed by everyone that round, then you get paid out proportionally when there's a block won.

and dealing with pooled mining, nbits doesnt really matter for your target, you're just targeting the pool difficulty. nBits will generally just be used for calculating the header and midstate.

ScalaMiner (https://github.com/colinrgodsey/scalaminer) will work with the 5-chip gridseeds with scypt (simultaneous btc/scrypt mining soon! already doing this with the 1 chip gridseed, and unfortunately have to configure frequency in code, can give u more instrunctions), but I have held off on gpu support for a bit =\ Soon for that too.

There's also the random gridseed cgminer fork, which works ok but crashes constantly when overclocking =\

annnnd im an asshole for not reading the thread well enough. sorry ckolivas =\

the newer version of cgminer has some formula for this (all possible values)


if thats too hard to read, here's the converted snippet from ScalaMiner (also probably hard to read... also untested, sorry)

**Version 0.2**

added Bitmain AntMiner U1/U2
ASICMiner Block Erupter USB

More 'icarus' like devices coming as soon as I can afford or verify in other ways.

also managed to max out power on my usb hub =\

dont remember what it actually means, but its part of the block header:

lol yea wow sorry about that. divide shift right if you're using a 2^n diff, divide by difficulty.

when using getwork, there should be a "target" field in the JSON response (should be data, hash1, and target).

target is the little-endian result of the divided dif 1 hash

targetBytes = bintToBytes(difMask / difficulty, 32).reverse //32 bytes

not sure the exact method for going backwards, but I think you can just do dif1hash / target

the max hash is going to be the difficulty 1 max hash (00000000ffff0000000000000000000000000000000000000000000000000000) shifted right by the difficulty.

so:

maxHash = 0x00000000ffff0000000000000000000000000000000000000000000000000000 >> difficulty;

if(hash > maxHash) tooShort(hash)
else goodToGo();

'short' actually refers to the hash being too low of a difficulty (bigger than it should be). thus with higher difficulty, the max acceptable becomes smaller, and harder to find a solution for.

correct except for the stratum connection part: stratum is a streaming protocol, so your connection to the server stays open the entire time. Reconnecting may actually give you a new extranonce1 and new job id which would invalidate your results, so you want to keep the connection open for any results you may submit.

but yea, extranonce1 is decided by the pool, and they tell you what size extranonce2 to randomly generate (usually 4 bytes), the device then  cycles through all the 2^32 nonce possibilities.

good question. im not totally sure what the justification is for this part of the hashing process, but ill try to explain what ive gathered...

theres 3 different nonce components in the header:

extranonce1 - used for merkle hash, provided by stratum host
extranonce2 - generated by the client! the stratum host will tell you the desired size in bytes (extranonce2_size, >= 4 i think). This number will also have to be submitted with the stratum results as well as the work nonce below.
the work nonce - the work guessing portion. these final 4 bytes must be 'guessed' by the mining device

initially, none of this made any damn sense to me, but it cleared up a bit

extranonce1 - still not sure why exactly its here, but ultimately its a source of entropy the pool picks
extranonce2 - source of entropy (randomness) from the mining client. with ScalaMiner, i wasnt doing this right initially and mining devices would have lots of 'collisions' (devices scanning the same work range). but technically if 2 different devices have a different extranonce2 value for each of them, they cant mine the same range, because the devices are only guessing 4 bytes of the header.
the work nonce - the final 4 bytes of the header, guessed by the mining device! each different extranonce2 and extranonce1 value will give us a completely new set of 2^32 4 bytes values to try for our work nonce range. most mining devices start at 0 for this value and just increment for each guess internally. if you give 2 devices the same extranonce1 and extranonce2, you'll often get identical nonce results, and ultimately duplicate shares.

some mining devices will also happily chew through the nonce range quickly and return no results. 2^32 = 4294967296 hashes, so at 10GH/s, it can chew through all possibilities in about half a second. the mining software at this point should know to submit new work to the device after this long (with a new extranonce2 value, giving it a brand new 2^32 possibilities to try). devices like the BFL BitForce SC line will let you queue up multiple jobs at once because otherwise you'd waste lots of time transferring new nonce ranges to the device.

So ultimately, for each device I start a counter at a random value and increment it randomly each time work is sent. thats the value I end up using for extraNonceInt in the code sample, which is then used to generate the extranonce2 value. giving two devices the same extranonce values can be detrimental, as you might not know they're mining duplicate shares until they finish

As far as I've seen, the extranonce2 info is always 4 bytes....

here's a snippet from ScalaMiner (https://github.com/colinrgodsey/scalaminer) for generating the header from stratum info (extraNonceInt is a randomly generated 32b int):

you should add https://github.com/colinrgodsey/scalaminer

Just launched the first 0.1 release of ScalaMiner! It's currently in beta, but im looking for a few people to check it out and help me test it. It's cross platform, so really all you should need is Java and a compatible device (or use the proxy). I'm pasting a snippet of the README below, but head to https://github.com/colinrgodsey/scalaminer for more information and installation etc...

Overview

ScalaMiner is a Scala/JVM implementation of several mining abilities available through software such as CGMiner and BFGMiner. This mining platform will give you a single performant process that can handle all of your mining device needs. Compatible with popular LTC/Scrypt and BTC/SHA256 mining devices (and more in the works), ScalaMiner will give you a stable, unified, cross-platform solution. It utilizes Akka actors for concurrency and usb4java/libusb for usb device control.

Goals

Provide a performant but fault-tolerant implementation of popular miner control.
Provide a portable and modular platform for mining device control, in which new driver implementation is neither destructive nor incompatible with existing drivers.
Provide a more efficient and performant stratum proxy for older devices.
Provide a durable hot-swap system that is tolerant of device failures. No more segfaults or disabled devices!
Utilize reactive programming principles to reduce overhead and enhance scalability.
Implement functionality in a distributed way that will take advantage of multi-core systems.
Support ARM devices, and keep a small RAM footprint (less than 100 MB)
Minimize kernel load to improve latency with USB and network devices.
Provide support for alternate JVMs (currently only tested in HotSpot 1.7 for ARM and x64)

Libraries

scrypt - Offers a pluggable native driver for extra performance
usb4java - requires libusb native driver. See their instructions on how to compile it if the included drivers are broken or don’t include your platform.
io.Usb - A fully reactive implementation of libusb using the akka.io framework, written specifically for ScalaMiner. Currently unpublished, but the code is available in this repo.
Akka - Amazingly strong actor-based concurrency platform for Scala/Java.
Spray - Akka actor based HTTP library using the akka.io framework.
SLF4J

Benefits

Akka actors provide a controlled mutability context within a parallel processing environment. This allows reactive principles to be implemented while relying on sequential access patterns for mutable data. This ultimately gives us an environment in which we can update state while seamlessly operating in a multi-threaded process. This functional distribution of concurrency units allows us to take advantage of a multi-core environment while respecting cache-coherency and freeing ourselves from mutexes and wait states. While avoiding wait/blocking states, we’re able to keep a lower thread counts, reduce context-switching and thread stack overhead.

Devices

Stratum Proxy - Implements a GetWork proxy that can be used with older devices to connect to a stratum pool. The fully concurrent proxy will give you much improved performance over the single-thread Python proxy by Slush.
GridSeed DualMiner - Support for either dual LTC/BTC or single LTC/BTC. No special procedure for dual mode! Just configure both a scrypt and sha256 stratum, set the switch on the device, and plug it in. Dual mode is detected per-device by only the switch, enabling you to run some devices in dual and some in single, all from the same process.
GridSeed 5-Chip 320kH/s ASIC GC3355 - Currently only LTC mode implemented (still trying to find non-conflicting specs).
Butterfly Labs BitForce SC - Single device only (no XLINK support). Has been tested with the 7.18 GH/s upgrade Jalapeno, should work with regular Jalapeno devices and the Little Singles.
Bitmain AntMiner U1/U2
ASICMiner Block Erupter USB

Hardware requests

The current device support for ScalaMiner is based on available access to mining hardware. If you are a hardware manufacturer/retailer/aficionado please file an issue request or contact me (colinrgodsey) otherwise to get the device support added!

Compiling/Configuring/Running

The project is managed with SBT. Running from source should be as simple as ./sbt run.
To prepare a bundled jar, use ./sbt assembly. This will create a jar with all deps and the default config in reference.conf (override using application.conf in the base dir).
See the Known Issues section below for instructions on how to compile the native driver if one of the provided ones doesn't work for you.
Configuration is done using Typesafe Config. Refer to the reference.conf file for config fields/structure. Place your overrides in application.conf in the base directory. Make sure to configure your pools, or it uses the default (as seen in reference.conf)!
More info coming soon....


Hardware support is rather limited! Basically developed and tested all of this on my frakenstein mining box::

Ordered 1 on 4/3/2012
Shipped today (5/21/12)

EXCITED!!!!

Is there a min? any fees?

Hmmm, nutz.

Looks like there's a few other places that offer MPW and prototyping stuff:

http://www.asicsystems.com/low-cost-ic-prototypes.htm
http://www.mosis.com

I'll have to actually try to get a quote, but i bet its more expensive =\ At lease there might not be an annual fee..