For the purposes of closing off the public convo here, we'll just have to agree to disagree then! We simply have different approaches to the same problem. I see your view on this as idealistic; trying to force miners to do things the way you believe is right (regardless of how much better it is) is unrealistic. I choose to approach it from what I see is a more practical vector. But, as you say: sharerate/hashrate measurement is possible either way, and seems to be the goal for many in here.

As I mentioned, this is a borrowed idea, and pseudo-standard in ALL proxies I came across (that I chose to spend time interpreting code on, that is). More importantly, I've confirmed this this approach works with my proxy with both bminer and dstm.

Will msg via PM now. If anyone else on the thread is interested in talking about stratum protocol, please PM me. Now back to your regularly scheduled bminer banter...

Any statum-like protocol requires sending a nonce1, as miners require it; it's their unique pool-designated nonce-space in which to generate solutions and this prevents duplicates at the pool - so yes, zpool must send it:


"810092d3" above is the nonce1. What equihash does NOT send (unlike other stratum-like protocols) is the nonce2_size (usually about 4), which indicates the size of the nonce2 solution the pool is expecting to receive in a "mining.submit" share.

Equihash takes a different approach, internally defining the total nonce size to be 32 bytes long (much bigger than other algos), so the miner (and also any proxy!) can calculate the length of the nonce2 it needs to generate to satisfy a total length of 32. So: 32 - len(nonce1) == <how long the generated nonce2 must be>


I disagree that it's easier done in the miner, but this is mostly a matter of perspective:

• My previous point about not being able to control/patch all miners means that if you take the approach of dictating to miners that they have to change their code to your way of thinking simply means that your proxy will not be compatible with miners that choose not to do so. Patching the code isn't the hard part; it's ensuring all miners do so.
• You certainly CAN patch miners to generate nonce2 values randomly; however given the same nonce1, there is still a small chance two rigs will randomly generate the same nonce2 value. This would still result in a duplicate share. The possibility is admittedly incredibly remote, but the chance is still there.

From a different point of view: a miner cannot control what other miners are doing; only the source of information can do that. In a pool -> miner relationship, the pool fills that role. If a proxy is put in the middle, then the proxy must serve that role for its connected miners.

This is literally the canonical proxy example, which does exactly what I'm saying. I'm not inventing this approach, I'm just describing something that already works and all but guarantees the avoidance of duplicate shares.

I don't think I'm misunderstanding you, in the case that I am, please correct me...

I've done a fair bit of research into proxies and the stratum protocol - I've been building a multi-coin proxy myself, we should compare notes - my findings are somewhat different than yours.

MANY mining devices/binaries will just start their calculations at zero and increment; I agree that it's somewhat better to 'randomly seed', but it IS perfectly valid to just increment.  You're right, with this type of tactic, in the multi-rig scenario you mention, it's absolutely possible and in fact highly likely to hit duplicate shares early without some sort of intervention.  However, the solution to this isn't in the miner (you cannot control how all past and future mining binaries will do this, after all).

Think about this for a second: the pool assigns each miner connection a unique nonce1 value. This gives each connection a unique 'nonce-space' in which to calculate solutions. If every connection to the pool is a miner, then there won't be any duplicate shares submitted. However, if a connection to the pool is a proxy, it still only receives a single nonce1 value and it has to 'share' that nonce1 value with all miners that connect to it. With this in mind...

The better solution lies in the proxy itself (particularly since you cannot control all miners out here)! If you examine how other proxies handle this, they 'assign' a unique nonce space to each miner connection by assigning one or two (unique) bytes per worker connection. For each miner connection to the proxy, this byte value is appended to the nonce1 value (originally received from the pool); and as you know the miner receives this unique nonce1 in their 'mining.subscribe' stratum request.

So, a proxy needs to send the pool's nonce1 + unique byte value per connection (ie. per rig) on subscription, and when a share is submitted from a rig the proxy needs to prepend the rig's unique byte value to the calculated nonce before sending it on to the pool.

There are caveats to this approach; with a single extra byte, you're limited to 256 miners connecting to that proxy. With 2 bytes extra, you get up to 65536 connections allowed. Most other popular proxies I've examined follow this approach, rather than rely on consensus and a common tactic used in miners.

I have this working, and have confirmed that bminer only supports up to 256 because it's hard-coded to only allow a single extra byte to be appended to the nonce (based on my investigation, I believe this was done to support Nicehash, which is like a proxy).

realbminer, if you're reading, you should really look at allowing another extra byte in the nonce1 length to give miners more flexibility - and more proxy compatibility.

Based on the above, I'd guess that '01000030' is the stratum protocol "mining.notify" method job version for whatever pool you're connecting to - it seems that 0.5.8 added support for '01000020', but now '01000030' is also required. Meaning, pools are updating their software, but miners need to catch up. Is this on nicehash or suprnova (based on your previous posts)?

dstm, if I'm on the right track here, have you investigated whether dropping any job version checks is feasible?

From my experimentation and investigation, the JSONRPC interface here isn't broken. Devs choose what 'transport' flavors to support - the most common by far in the mining space is JSONRPC over plain sockets (either plaintext or TLS secured). "JSONRPC over HTTP" isn't frequently supported that I've seen.

I imagine dstm's decision for the stats/telemetry API was largely based on the informal consensus in the community to implement stratum spec with plain sockets only.

(Edit: I'm open to being wrong here... just observations based on what I've seen.)

I would also like to know what protocol v.01000020 is?

1. yes
2. yes
3. no to needing to be 'online' (the blockchain will record all-the -things), but your ZCL/BTC will need to be at an address you control (in a wallet or on an exchange that will support the fork - just get it into a wallet you control the keys for, that's safest)
4. one can expect a surge or a drop or both

I'm using zcl.suprnova.cc; no major complaints besides the fact that their web UI is slow. However I would like to know how you're determining that they're not doing well for you in case I'm missing something.

You probably know this already, but the miner's hashrate will almost always be different from that of the pool. The miner shows the actual hashrate based on the real GPU work done (unless the miner is inflating its numbers to look better, but we kind of have to 'trust' them). The pool calculates your hashrate based on the number and frequency of accepted shares you send in. The sending of shares by the miner to the pool is an intermittent activity, sometimes you'll get two in a minute, other times you wait several minutes between shares (it IS guess-work, after all).

But to better understand the issue, it would be helpful to give some numbers from both the miner and suprnova, so people can help out.

• What miner (mining software) are you using?
• What are your rig(s) configuration/setup? How many GPUs, etc?
• Do you overclock? What are your settings
• How long did you run the miner for on this pool before determining it's 'low'?

There are a lot of factors, obviously.

I wrote a little script to pull share/hash rate & earning stats from suprnova's API - I only use it for 'real-time' display purposes, but I'm thinking of storing historical data so I can see things over time and better determine success vs problematic behaviour.

Anyhow, in answer to your real question, I can safely say, don't use zclmine.pro. I had major latency issues when submitting shares.

realbminer, it almost sounds like a stratum protocol parsing issue, specific to the one pool's implementation? Although, PIR3lly stated that it ran well for a day before starting to fail.

Perhaps something related to the mining 'session' (re: mining.subscribe ID used to resubscribe after disconnect) - not sure if bminer supports resuming mining sessions. Given the slow, staggered startup, I'm guessing 'no'. (and it's very unlikely that it would resume between fresh bminer starts, anyway) But if so, maybe starting subscribing fresh, without resuming would help?

If you didn't, try going through the process of finding the best OC settings for your cards using bminer. I found that the results could be quite a bit better compared to just using the ewbf OC settings.

Overall, I found that dstm and bminer seemed to perform their respective best with same OC settings (again, different than the 'best' OC settings for ewbf), with bminer providing a slightly higher hashrate.

My original post was here (because I didn't want to resurrect an old thread necessarily, I see now I was wrong): https://bitcointalk.org/index.php?topic=2768236.0

My main question at the moment is around the various transports mentioned:

The 'spec' defines 4 transports: Socket transport, Websocket, HTTP Poll, and HTTP Push (which is a variation of HTTP Poll). I get the feeling that much has changed since stratum was first introduced, so I'm wondering if all 4 protocols are still needed/used - is it necessary to implement them all in a proxy? What about if one was implementing a pool? For example, if miners have moved towards supporting plain TCP Socket transport only, there's no point in implementing the other 3 transports.

This topic has been moved to Mining software (miners) - I didn't realize something much more specific to protocol implementation existed. Someday, I'll learn my way around BCT.

https://bitcointalk.org/index.php?topic=2768236.0

This topic has been moved to Pools (Altcoins), because the conversation and members there should be more relevant.

https://bitcointalk.org/index.php?topic=2768236.0

I think you ought to be able to do SSL with just the plain TCP socket - it's just a 'modification' to the socket transport layer. I'm pretty sure that miners that support SSL are doing it this way. Remember, HTTPS != SSL; HTTPS == HTTP on top of SSL-enabled sockets.  I suppose the proper term these days is TLS though...


That is interesting to note! Thanks for your reply.

So anecdotally speaking from the evidence presented by 1 response, I can safely say that TCP and SSL+TCP socket streams are all that's needed!    Would love further feedback as well.

As an exercise, I'm toying with building a stratum proxy. I know they already exist, but I'm looking to experiment with some more recent tech and this seems like a good project.

This BCT thread is a good starting point for the stratum protocol. Along with the 'canonical' stratum protocol google doc and slushpool's stratum overview, there's a fair bit to digest. Definitely not a true spec, but enough to work with.

The 'spec' defines 4 transports: Socket transport, Websocket, HTTP Poll, and HTTP Push (which is a variation of HTTP Poll). I get the feeling that much has changed since stratum was first introduced, so I'm wondering if all 4 protocols are still needed/used - is it necessary to implement them all in a proxy? What about if one was implementing a pool? For example, if miners have moved towards supporting plain TCP Socket transport only, there's no point in implementing the other 3 transports.

 - Let me know if there's a better forum board for this post - I'll move it if needed.

I feel that this is low for your cards? I've got 6x 1070s and I've earned 0.188 per day (averaged the last week's 1.319 earnings). Maybe I'm wrong.

Thanks for the replies, everyone. Camping out at a local shop isn't really an option for me, unfortunately - there's nothing of any size nearby, so I'm left with ordering online. I've backordered on a couple of sites, and one gave me this pleasant (but unfortunate) response:


Yeesh.

I suppose I should try to avoid uniform rig-building efforts (ie. identical n brand/model GPUs) if I'm ever going to complete my 8 unit rig (sitting at 6 now).

In North America, how the hell does one get ahold of GPUs? I'm looking for 1070s but everything's been sold out for a while now. I realize not many people will be willing to share their sources/methods, but seriously: how are people still able to source hardware?

Maybe I'm too noob.

Depends on what algorithm you want to mine. For equihash, take a look and compare the following:

• tpruvot's fork of ccminer seems to be the most active ccminer fork that I've seen; of course ccminer handles multiple algorithms, which is handy
• ewbf is a custom equihash miner, hasn't been updated in a while
• dstm is a custom equihash miner, actively maintained and is more recent and hashes faster than ewbf
• bminer is a custom equihash miner, actively maintained and is more recent and hashes faster than both ewbf and dstm (marginally so for dstm, but still)

All three have devfees and can be disabled, usually with a performance decrease (CPU/GPU optimizations are disabled).

I'm using zcl.suprnova.cc, seems legit. Web interface is a bit laggy, but otherwise the service seems ok.