"difficulty-multiplier" needs to be settable per pool

[badman74]

currently it is only settable globally which makes some pools unusable
edit: this probably wouldn't even be necessary if the pools were always setup right

[luke-jr]

I suggest just always interpreting mining.set_difficulty as bdiff like the stratum spec says, and telling broken pools they need to fix themselves. If all mining software takes this stance, they will have to fix.

[mrbrdo]

I also agree with luke-jr. Let's not stimulate bad practices if we can help it.

Also I guess then we must make a decision to either remove this option entirely, or make it per-pool configurable. Probably some people will be pissed if we remove it, but that shouldn't affect the decision.

Unless there is a valid use-case for this option even when pools are properly configured?

[badman74]

pretty sure it is useless for properly configured pools

[CodeChief]

I'm all for standards too but @luke-jr you're also making a breaking change when the behaviour of one version to the next (namely v3.10 to 4.x) stops working with popular software. A better way of doing it would have been to add a setting like the setting being proposed here along with a start-up warning displaying the calculated number people need to get the old behaviour. Then users can carry-on using it for a few versions but know they have to request the other tool be updated ASAP.

So for SGMiner devs I say please think about this. Never change the behaviour without giving us a way forwards. We need the fixes and any performance improvements in your new versions. But there are so many other components to consider we cannot make such hard changes that fast. The other tools need time to update.

If I understood the various wikis correctly, you could argue the long established behaviour of alt-coins relative to (there's the difficulty multiplier requirement) bitcoin is more of a standard (at least for alt-coins) than what the (absolutely bitcoin focused and potentially biased) Bitcoin Foundation designed when introducing the stratum protocol to short-circuit the more open GetBlockTemplate contract. So I wouldn't point the finger so easily at the alt-coin behaviour being wrong.

https://en.bitcoin.it/wiki/Stratum#Criticism

Edit - if that's true it makes me wonder why the community has not demanded full GBT support. If the miner already supports it and it is as fast, then is it the pool software which must be updated? If so then that's certainly something I'd like to contribute to, unless the GBT developers have all given-up already. Any background on that relative to this issue (hoping it would deal with these difficulties in a more alt-coin compatible way) would be helpful.

[mrbrdo]

We can deprecate it (support but with warnings) and remove in next major version.

[luke-jr]

@CodeChief Major version bumps are expected to break compatibility where sensible. BFGMiner fixed this for scrypt in 4.0 while still providing backward compatibility by misinterpreting integer difficulty values over 1 (which is insanely high for scrypt or probably any other not-really-a-PoW algo) - that might be a way forward too, at least short-term (I'm not currently displaying a warning for this issue). Neither the Bitcoin Foundation nor the wider Bitcoin community were not involved in the development of Stratum.

GBT development is progressing slowly, but is currently only properly supported by BFGMiner (although the brains for it are implemented in MIT-licensed libblkmaker which sgminer could make use of too). Note that GBT being a decentralised mining protocol, is tightly tied to Bitcoin, and may not work sanely with some altcoins.

[CodeChief]

@luke-jr okay thanks for the clarification it's clearly not as simple as what I gathered from the various bits of information available. I'm interested but will have to go and learn a lot more and study the source in depth before I can contribute in that area. Sounds like GBT is a P2Pool itself if not the underlying technology. Maybe there's a history lesson there too.

I'm quite motivated to simplify all this difficulty stuff if it is going to be a long term or recurring issue. Many miners don't have a clue what all these numbers mean and just want the G/M/K-hash of course. Hopefully this could all be automatic in the future or some kind of calculator could be developed.

I read that pools implement their own adjustment logic for this and to protect themselves from being overwhelmed with inefficient submissions. P2Pool obviously needs some kind of similar logic and WeMineAll might need to improve theirs, assuming many more people had my experience.

[mrbrdo]

@luke-jr actually it's not always like that, it is becoming quite common to deprecate a feature in a major version (e.g. 5.0) and then remove it in the next minor version (e.g. 5.1).

[luke-jr]

@mrbrdo Yes, I do that myself (actually, I haven't removed the 4.0-deprecated things even in 4.3 yet...), but I'm considering it as a "break" when the "supported way to do it" changes. :)

[mrbrdo]

Fixed via 30d0a9b and #317