Topic: [ANN] Stratum mining protocol - ASIC ready (Read 145767 times)

Could someone briefly describe how extranonce2 is used ?

A normal stratum error is fine.
{"id": whatever id the request has, "result": null, "error": (20, "Not supported", null)}

Could someone explain me what is the purpose of the mining.get_transactions stratum extension  ?

I am the developper of the stratum proxy https://github.com/Stratehm/stratum-proxy and someone reported me that the last BFGminer versions does not work with my proxy due to this extension. What should the pool respond if it does not support this extension ?

Thanks and merry Christmas 

What does it solve?
I'd wonder about adding functionality for no clear reason given, though that seems to be the new way.

That's a reasonable request and I agree that using the originally documented syntax is a good starting place. Since JSON is capable of coping with pretty much any sort of data, I propose that if we do implement it, that it is a simple unit such as hashes/second. While the values obviously returned with this will be very large, I don't think this is of any real consequence since the management of the data is up to the server/client but json itself will easily cope with massive values there and having it as a "unit value" will be advantageous and flexible.

On the other hand, I can see serious issues with trying to implement this at the client end. Most client software does not know in advance what the hashrate of the hardware is until it has actually been mining for some time anyway (for at least a minute or so) by which time most half decent pool software will probably have some idea of what the hashrate will be anyway. Which means that apart from embedded hardware with an expected pre-determined hashrate (like an S3 or a spondoolies sp2/30), the client can't really accurately report the hashrate till after it's been mining for a while anyway. The only way it could report a hashrate is if the user consciously set up the miner giving the expected hashrate as "hint" to the client software such as --expected-hashrate 10000000 or something like that. If the miner already knows this and is manually inputting it, then there's no real advantage to doing that at the client end instead of the pool end as either telling the pool the hashrate or choosing a diff.

In short, I'm not against this stratum feature being implemented, but I think it's probably being hopeful that it will solve whatever problems the upstream pool is having by not knowing the hashrate in advance which a well coded pool hashrate estimator should work out itself.

slush proposed a mining.get_hashrate for this a while ago... not sure if there's any specification/documentation of it though.

Feature proposal: client report hashing speed

It would be very useful for stratum protocol to include a client message to report hashing speed. Today's miners (SHA256, Scrypt and others) vary a lot in terms of speed. For efficient initial vardiff handling, initial miners distribution in dependence of speed, etc. it wold be very useful for a pool to be informed by the client at what speed it is hashing. It would be nice if this would be implemented in the stratum protocol.

i need a stratum that take one connection but then connect to multiple pool using multiple worker, with something like "--balance" for cgminer, i know slush stratum can't do this, there is something else

That I can see,Anything more u can add like how to fix this?

 Couldn't listen on 0.0.0.0:8332

I encountered an error while running stratum mining proxy


Anybocy could help me?

Trollololol

Ah alrighty, I'll stick with Stratum then. And BFGMiner, appreciate the help with clearing some things up. If I need anything else Ill shoot you a PM or something in the future Likely with those miners and getting them running with bfgminer.

GBT is pretty tightly related to Bitcoin specifically.
I don't know if any altcoins have put the effort into properly porting it.

Ah, yea forgot cgminer dropped scrypt support. Haven't done mining myself in a while. Doing some research on a large scale project I'm doing. I expect that they will provide you with enough information to give you support. Otherwise they lose business :p Haven't decided between stratum or gbt yet. Very large scale mining operation, have to be able to switch coins on the go. set extranonce lets me do this in stratum. Havent looked too much into gbt yet however.

That's mostly up to the manufacturers to provide documentation and sample units to work with (obviously if this is needed *at* shipping time, the docs at least would be needed *prior* to shipping).
cgminer certainly won't - it doesn't support scrypt at all (which the brands you mention are for).

Likely will, do you plan on supporting the new titans and vaultbreakers? Not sure how mining software goes about supporting new hardware. I will need support for very high mhs scrypt machines as soon as they ship.

Could just tell them to upgrade to BFGMiner...

I do, however, require support for set_extranonce. I'll do my own build of cgminer then. Just a pain to get users to use it rather than what they already have. Thanks for the reply.

cgminer doesn't support most things, just the minimum necessity for specific use cases.
Generally, you shouldn't need mining.set_extranonce, though.