Stratum protocol discussion

[-ck]

Discussion goes here 

[Luke-Jr]

2013 Feb, after discussion, mining.subscribe was extended to take 2 arguments, so now it's mining.subscribe(String useragent, sessionid) where sessionid is optional, but if provided must match a previous session's mining.notify subscription id. If the server allows resuming a session, it will give you back the same subscription id and extranonce information.

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

[kano]

...
BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

Why would it do this?
There is already mining.suggest_difficulty(difficulty)
Someone didn't read the docs and added it to their non-standard miner clone?

[Luke-Jr]

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

Why would it do this?
There is already mining.suggest_difficulty(difficulty)

No, there isn't. Nothing implements this, and it isn't documented anywhere.

Using a target fixes the inherent problems with using difficulty as a Number:

• There is no agreement over which difficulty measurement is to be used. The official spec says bdiff; BTCGuild uses pdiff; various scrypt pools use Ldiff
• Some common targets (such as pdiff 1) cannot be accurately conveyed without huge data sizes
• Implementing conversion to/from difficulty accurately requires a bignum library, so often (eg, *gminer) it is just approximated.

[CaptEmulation]

Let me be the first to say thank you first designing, implementing and now collecting this information for all.  Much more concise reading than https://bitcointalk.org/index.php?topic=108533.660 or what else I've found on the pools pages.

[kano]

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

Why would it do this?
There is already mining.suggest_difficulty(difficulty)

No, there isn't. Nothing implements this, and it isn't documented anywhere.

If you say something that contradicts facts in front of your face, oddly enough, that just makes you look foolish.
Try a little sense in your posts.

One of the posts above, shows where it was documented, over a year ago:
https://bitcointalk.org/index.php?topic=108533.msg1543341#msg1543341

Edit: and of course on the same page:
https://bitcointalk.org/index.php?topic=108533.msg1543185#msg1543185

[Luke-Jr]

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

Why would it do this?
There is already mining.suggest_difficulty(difficulty)

No, there isn't. Nothing implements this, and it isn't documented anywhere.

If you say something that contradicts facts in front of your face, oddly enough, that just makes you look foolish.
Try a little sense in your posts.

One of the posts above, shows where it was documented, over a year ago:
https://bitcointalk.org/index.php?topic=108533.msg1543341#msg1543341

Forum posts are not documentation.

[kano]

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

Why would it do this?
There is already mining.suggest_difficulty(difficulty)

No, there isn't. Nothing implements this, and it isn't documented anywhere.

If you say something that contradicts facts in front of your face, oddly enough, that just makes you look foolish.
Try a little sense in your posts.

One of the posts above, shows where it was documented, over a year ago:
https://bitcointalk.org/index.php?topic=108533.msg1543341#msg1543341

Forum posts are not documentation.

You've been flipping too many burgers at McDonalds - it's softening your brain and you are forgetting things:
https://bitcointalk.org/index.php?topic=108533.msg1543185#msg1543185

But I guess that's to be expected.

[Luke-Jr]

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

Why would it do this?
There is already mining.suggest_difficulty(difficulty)

No, there isn't. Nothing implements this, and it isn't documented anywhere.

If you say something that contradicts facts in front of your face, oddly enough, that just makes you look foolish.
Try a little sense in your posts.

One of the posts above, shows where it was documented, over a year ago:
https://bitcointalk.org/index.php?topic=108533.msg1543341#msg1543341

Forum posts are not documentation.

You've been flipping too many burgers at McDonalds - it's softening your brain and you are forgetting things:
https://bitcointalk.org/index.php?topic=108533.msg1543185#msg1543185

But I guess that's to be expected.

Hard to see how I forget something I never read in the first place.
I don't see anything relevant there anyway. Con agreed to implement slush's spec and then never did. How is this relevant?

[-ck]

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

Why would it do this?
There is already mining.suggest_difficulty(difficulty)

No, there isn't. Nothing implements this, and it isn't documented anywhere.

Using a target fixes the inherent problems with using difficulty as a Number:

• There is no agreement over which difficulty measurement is to be used. The official spec says bdiff; BTCGuild uses pdiff; various scrypt pools use Ldiff
• Some common targets (such as pdiff 1) cannot be accurately conveyed without huge data sizes
• Implementing conversion to/from difficulty accurately requires a bignum library, so often (eg, *gminer) it is just approximated.

Seems like a valid concern to me since it was described over a year ago and yours isn't documented anywhere except as part of your code. Of course you're free to implement whatever you want on top of stratum. Cgminer happily works with any arbitrary diffs and does not have problems with the accuracy of the shares it returns in response, using true diff 1 as the base for all stratum operations. I wasn't aware there was any controversy about the move to true diff1; that old simplification only affected getwork. Since work in stratum is even defined in terms of difficulty, it makes even less sense to then request a difficulty as a target. I don't see a problem with you using it for your software and your pool but I can't see why it should be seen as part of the stratum spec.

[gmaxwell]

From a protocol development perspective, stratum being defined in terms of difficulty is an embarrassing flaw of the sort that would have been avoided if it hadn't been developed behind closed doors. ... The fact that it's a floating point value which cannot precisely specify the actual values used in bitcoin is a pretty big facepalm.  All of this really should have been using bits like the bitcoin protocol does both for precision and consistency sake (or an expanded target— to accommodate legacy stupidity, but then again people will just get the byte order confused and complain it wastes bandwidth. ).

In any case, should have beens aside— what am I missing here?  There is no formal specification for stratum at all, slush was apparently sucked into Trezor land before publishing it.  AFAICT nothing is implementing the difficulty based message that was suggested way in the past, but at least luke's stuff has implemented the target based approach.  Whats to debate?

[kano]

From a protocol development perspective, stratum being defined in terms of difficulty is an embarrassing flaw of the sort that would have been avoided if it hadn't been developed behind closed doors.
...

It wasn't developed behind closed doors, you are just regurgitating a lie spread by Luke.

[Luke-Jr]

Here we go again  :-

Let the undocumented stuff coexist, it's rather unimportant anyway since most pools couldn't care less what the miner wants.

+1, suggest splitting side-discussion off to leave the thread to just the documentation posts.

[Luke-Jr]

2013 Feb, after discussion, mining.subscribe was extended to take 2 arguments, so now it's mining.subscribe(String useragent, sessionid) where sessionid is optional, but if provided must match a previous session's mining.notify subscription id. If the server allows resuming a session, it will give you back the same subscription id and extranonce information.

BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.

This post should have been on the other side of the split.

[irrational]

Forum posts are not documentation.

As someone who's working on a Stratum implementation right now, I must say this is a VERY narrow view of reality.

I've been using the following resources to gain my knowledge of the protocol:
https://bitcointalk.org/index.php?topic=55842.0
https://bitcointalk.org/index.php?topic=108533.0
http://mining.bitcoin.cz/stratum-mining
https://www.btcguild.com/new_protocol.php

Notice how 50% of those links were forum posts   

But, I'm guessing none of the discussion here counts as documentation either and can be entirely ignored 

[-ck]

As someone who's working on a Stratum implementation right now, I must say this is a VERY narrow view of reality.

I've been using the following resources to gain my knowledge of the protocol:
https://bitcointalk.org/index.php?topic=55842.0
https://bitcointalk.org/index.php?topic=108533.0
http://mining.bitcoin.cz/stratum-mining
https://www.btcguild.com/new_protocol.php

Notice how 50% of those links were forum posts   

But, I'm guessing none of the discussion here counts as documentation either and can be entirely ignored 

Did you miss this sticky post?
https://bitcointalk.org/index.php?topic=557866.0
It's as close as it gets to the repository of the collated official documentation which was never written, only the draft proposal by slush which is quoted there.

[irrational]

Did you miss this sticky post?

I DID!!!!

Thank you!

Since we're talking drafts, and implementation. Both that sticky, and I think Slush's website, mention HTTP Poll as an optional transport mechanism. Do any mining apps support HTTP Poll? Standard TCP sockets seems to be the prevailing implementation.

[Luke-Jr]

As someone who's working on a Stratum implementation right now, I must say this is a VERY narrow view of reality.

I've been using the following resources to gain my knowledge of the protocol:
https://bitcointalk.org/index.php?topic=55842.0
https://bitcointalk.org/index.php?topic=108533.0
http://mining.bitcoin.cz/stratum-mining
https://www.btcguild.com/new_protocol.php

Notice how 50% of those links were forum posts   

You're free to reference whatever you want, but that doesn't change what "documentation" means.

But, I'm guessing none of the discussion here counts as documentation either and can be entirely ignored 

Feel free to ignore the forum posts.
Unlike stratum, getblocktemplate is properly documented in Bitcoin standards and the wiki.

https://en.bitcoin.it/wiki/Getblocktemplate
https://en.bitcoin.it/wiki/BIP_0022
https://en.bitcoin.it/wiki/BIP_0023

[gmaxwell]

It wasn't developed behind closed doors, you are just regurgitating

The initial development was secret to the public before it was up on slush's pool along with the python proxy. I'd always understood this to be a (anti- )competitive move.

There remains no BIP describing it, there was no design discussion prior to its release on bitcoin-development. Justifying the closed development, Slush wrote (in the second email my mailbox ever received mentioning stratum mining) "There's no requirement to have BIP for everything what people do. Stratum is NOT related to bitcoin protocol or bitcoin implementation, it is just custom, pooled-mining extension and bitcoin network doesn't need to know about Stratum existence at all."  Perhaps you were somehow an insider on it— if so, why didn't you discourage some of the poor choices in it?  But from my own perspective it really was developed in secret and, in my opinion, carries some of the predictable flaws of a protocol developed without broad input. It's not the end of the world, in any case. Far worse has been done elsewhere.

[kano]

No doubt Luke will claim ignorance of the relevance of this link to the discussion, but it is quite obviously relevant to anyone with the intelligence level necessary to understand ...
https://bitcointalk.org/index.php?topic=108533.msg1180529#msg1180529