mining.configure is a redundant reinvention of the mining.capabilities in use since 2014

[luke-jr]

It literally does the exact same thing, but is otherwise incompatible for no reason. The protocol herein should be fixed to use the existing mining.capabilities method instead.

[janbraiins]

Is there any documentation except for this feature except for this draft mentioned on the bitcoin wiki?

[luke-jr]

Not AFAIK. That "draft" is what eventually became the final protocol, as no further changes were needed.

[luke-jr]

FWIW, this is a compatible spec in the current BIP draft:

===Stratum mining protocol===
The mining.capabilities method should be used by clients to inform the server that they support the mining.set_version_mask method.
For example:

    mining.capabilities({"notify":[], "set_difficulty":{}, "set_version_mask":{“mask”: “ffffffff”})
    {“id”: null, “method”, “mining.capabilities”, “params”: [{"notify":[], "set_difficulty":{}, "set_version_mask":{“mask”: “ffffffff”}]}

The optional “mask” parameter may be used to specify the specific bits the client supports manipulating.

If supported by the server, it will issue one or more mining.set_version_mask notifications, like so:

    mining.set_version_mask("1fffe000")
    {"id": null, "method": "mining.set_version_mask", "params":["1fffe000"]}

The new version mask affects new mining.notify jobs only.

Once (and only if) the client has been authorised to modify bits, it should submit the block version as a hexadecimal string with all mining.submit requests as an additional (6th) parameter.

[janbraiins]

Luke, just wondering, where is this draft to be seen? I have search bitcoin bips and couldn't find it, maybe I missed something.

[luke-jr]

https://docs.google.com/document/d/1GedKia78NUAtylCzeRD3lMlLrpPVBFg9TV9LRqvStak/edit?usp=sharing

[janbraiins]

the capabilities method has different semantics. There is no response, it's only one way communication from the miner telling hey-i-can-do-this. And that is the reason why we chose a new method name, that properly requests some features - in this case e.g. 'version-rolling' and the server responds whether it supports this feature or not + additional config values

[luke-jr]

The response was undefined. It's not a break to simply define the response.

[janbraiins]

Well, our point is that mining.capabilities was not any kind of well documented/used standard. At least that's what it looked like. And I believe you have just identified the point. It's a bit too complex having methods that may/may not have a response. Very confusing for the mining software. The configuration/capabilities setup should be very deterministic.

[luke-jr]

There has never been a need for a reply to it. (And still isn't with version rolling, for that matter.)

Adding capabilities required a trial-and-error: if the server disconnects, we need to retry without it. Now, adding yet another reinvention of it for no reason, mining software needs to try yet again... try with mining.capabilities; if that's rejected, retry with mining.configure; if that's rejected, try the ancient stratum.

It makes far more sense to just specify the return value for mining.capabilities.

[janbraiins]

I have posted link to our discussion to bitcoin-dev, let's collect more feedback. The point is that the ball is already rolling with the new hardware coming to the market.