support non-hexadecimal job_id

[lolliedieb]

support non-hexadecimal job_id

[Lolliedieb]

Hello, can you tell me for which coin this is, then I can fix that.
One thing that you should be aware of that is if a jobid is not numeric its harder (internally in my miner) to compare it to the current running calculations on gpu, so diverging from stratum standard may end up in more stale shares send). But I am willing to look into this.

[wincss]

It's ycash. (I have already fix it on pool-side by using hexadecimal job_id.)
There had been same problem on BEAM pool before I fixed it on January.

Our zcash, zclassic, zencash (horizen) pools are still using non-hexadecimal job_id now, but Equihash 200,9 coins are mined by ASIC miner, so no one complains about this.

Does stratum standard has requirements about job_id? Could you give me some documents about that?

[Lolliedieb]

Well that always depends on the coin - most Equihash coins use the same Stratum basis.
For Beam the spec is here
https://github.com/BeamMW/beam/wiki/Beam-mining-protocol-API-(Stratum)
which is quite minimal (and there are no types written for the data what is quite bad) - but the reference node implement is only sending out integer values, not even hex ones.

Sometimes its a bit difficult to handle that all since the specs are often not precise.

[wincss]

Yes, there is no enough details about job_id in stratum protocol document.

We have run our bitcoin pool since 2013. Other coins' pools is derived from the origin bitcoin pool which using a non-hexadecimal job_id. I also found some other pool operator using UUID as job_id. (It seems that UUID is compatible with your miner since it always starts with hexadecimal characters.)

We will care about job_id when we develop other mining pools.

[Lolliedieb]

Should work in 1.0 (well ... already way earlier ^^)