Unfortunately this site no longer contains the documentation for stratum.
You'll need to look here:
https://bitcointalksearch.org/topic/stratum-protocol-documentation-557866
Topic: Stratum protocol discussion (Read 9111 times)
Slush has posted an official page for the stratum protocol now, including new extensions.
http://stratumprotocol.org/
http://stratumprotocol.org/stratum-extensions
Of note, the most important extension added is: mining.configure which supports “version-rolling”
The executive summary is that version-rolling means poolside support for asicboost. Asicboost is now under the defensive patent license meaning anyone can add it to their hardware provided they sign the DPL.
http://stratumprotocol.org/
http://stratumprotocol.org/stratum-extensions
Of note, the most important extension added is: mining.configure which supports “version-rolling”
The executive summary is that version-rolling means poolside support for asicboost. Asicboost is now under the defensive patent license meaning anyone can add it to their hardware provided they sign the DPL.
Ah, of course, because the pool's reward address is in included in what's being hashed. Thanks.
Hi, I'm new to the forum.
It's been hard to find any complete documentation on stratum, but I've read through a few posts here, slushpool, and bitcoin.it docs.
One thing I still don't understand is how stratum can prevent a malicious mining from taking a newly found share test it for validity at the full network difficulty, and if it is valid, submit it for themselves, instead of to the pool via stratum. If this was problem was not solved, they would submit the shares via stratum to the pool only if they were not valid, making double the amount until someone realizes they are probably cheating.
Anyone care to enlighten?
Coz you can't change the data to go somewhere else - that will produce a different hash.It's been hard to find any complete documentation on stratum, but I've read through a few posts here, slushpool, and bitcoin.it docs.
One thing I still don't understand is how stratum can prevent a malicious mining from taking a newly found share test it for validity at the full network difficulty, and if it is valid, submit it for themselves, instead of to the pool via stratum. If this was problem was not solved, they would submit the shares via stratum to the pool only if they were not valid, making double the amount until someone realizes they are probably cheating.
Anyone care to enlighten?
When you find a block, it depends on hashing the block reward output also.
Yeah they worked that out in the original design 9 years ago fortunately
Hi, I'm new to the forum.
It's been hard to find any complete documentation on stratum, but I've read through a few posts here, slushpool, and bitcoin.it docs.
One thing I still don't understand is how stratum can prevent a malicious mining from taking a newly found share test it for validity at the full network difficulty, and if it is valid, submit it for themselves, instead of to the pool via stratum. If this was problem was not solved, they would submit the shares via stratum to the pool only if they were not valid, making double the amount until someone realizes they are probably cheating.
Anyone care to enlighten?
It's been hard to find any complete documentation on stratum, but I've read through a few posts here, slushpool, and bitcoin.it docs.
One thing I still don't understand is how stratum can prevent a malicious mining from taking a newly found share test it for validity at the full network difficulty, and if it is valid, submit it for themselves, instead of to the pool via stratum. If this was problem was not solved, they would submit the shares via stratum to the pool only if they were not valid, making double the amount until someone realizes they are probably cheating.
Anyone care to enlighten?
It's all just Socket.
My original post was here (because I didn't want to resurrect an old thread necessarily, I see now I was wrong): https://bitcointalksearch.org/topic/help-with-stratum-protocoltransport-questions-2768236
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.
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.
The wiki version includes the no so-nice hash hack that is a major security issue for miners
What are you talking about here?Stratum is fine except for 2 things.
1) difficulty isn't associated with work
Solution that resolved this: difficulty affects the next work item
2) the initial connection is convoluted for the miner
Cause of this problem: Getwork and GBT
Solution: well no one has done it, but it would be best to just ignore getwork and GBT connections and throw them away
cgminer already ignores getwork connections
1) difficulty isn't associated with work
Solution that resolved this: difficulty affects the next work item
2) the initial connection is convoluted for the miner
Cause of this problem: Getwork and GBT
Solution: well no one has done it, but it would be best to just ignore getwork and GBT connections and throw them away
cgminer already ignores getwork connections
Stratum uses too much bandwidth. I would like to see a zeroconf mining protocol which could deliver new job notifications to every miner in a big farm (same network) with only one packet from the pool server.
You do not need Cisco for this job. Your goal is to force other people do work for you so you can save a bug from hosting expnses right I like your style though Some thorny from l2 networking if that is what you REALY want ...please note you will still gona need 5 usd switches here and there in the big farm
In general what you need is multicast and some strtum miner hacks
As a big pool op it will be a peace of cake for you to make first two. But for the third one you need to have the sources of your crappy CHINESE borders miners fork. And as we all know it is a top secret STOLLEN FROM COMMUNITY and it is CLOSED. And you will have to pay a lot of money to your brothers to get ti;D
. What a irony dude 
The wiki version includes the no so-nice hash hack that is a major security issue for miners
What are you talking about here?The wiki version includes the no so-nice hash hack that is a major security issue for miners
What are you talking about here?
That would be the job of a proxy, but not ideal for a pool.
So yes it could be an addition to the stratum protocol, but would not be ideal for a pool to use it.
The basis of course would be to remove the variable information from the work notification and keep that extra state information in both the work source (proxy) and the miner.
So I'd guess it would be best implemented under a new name ... whatever, whoever
e.g. as a suggestion
mining.zerostate to define the state information for all following: mining.zeronotify to send work without the state information
You'd have to watch out, again, to avoid the 'difficulty' issue that would also have the same issue with 'state'
(that is resolved by defining what 'difficulty' and 'state' applies to rather than having it part of the notify)
So yes it could be an addition to the stratum protocol, but would not be ideal for a pool to use it.
The basis of course would be to remove the variable information from the work notification and keep that extra state information in both the work source (proxy) and the miner.
So I'd guess it would be best implemented under a new name ... whatever, whoever
e.g. as a suggestion
mining.zerostate to define the state information for all following: mining.zeronotify to send work without the state information
You'd have to watch out, again, to avoid the 'difficulty' issue that would also have the same issue with 'state'
(that is resolved by defining what 'difficulty' and 'state' applies to rather than having it part of the notify)
Stratum is fine except for 2 things.
1) difficulty isn't associated with work
Solution that resolved this: difficulty affects the next work item
2) the initial connection is convoluted for the miner
Cause of this problem: Getwork and GBT
Solution: well no one has done it, but it would be best to just ignore getwork and GBT connections and throw them away
cgminer already ignores getwork connections
1) difficulty isn't associated with work
Solution that resolved this: difficulty affects the next work item
2) the initial connection is convoluted for the miner
Cause of this problem: Getwork and GBT
Solution: well no one has done it, but it would be best to just ignore getwork and GBT connections and throw them away
cgminer already ignores getwork connections
Stratum uses too much bandwidth. I would like to see a zeroconf mining protocol which could deliver new job notifications to every miner in a big farm (same network) with only one packet from the pool server.
Stratum is fine except for 2 things.
1) difficulty isn't associated with work
Solution that resolved this: difficulty affects the next work item
2) the initial connection is convoluted for the miner
Cause of this problem: Getwork and GBT
Solution: well no one has done it, but it would be best to just ignore getwork and GBT connections and throw them away
cgminer already ignores getwork connections
Edit: also read the stratum definition in this thread: https://bitcointalksearch.org/topic/stratum-protocol-documentation-557866 (also linked in my sig)
The wiki version includes the no so-nice hash hack that is a major security issue for miners
1) difficulty isn't associated with work
Solution that resolved this: difficulty affects the next work item
2) the initial connection is convoluted for the miner
Cause of this problem: Getwork and GBT
Solution: well no one has done it, but it would be best to just ignore getwork and GBT connections and throw them away
cgminer already ignores getwork connections
Edit: also read the stratum definition in this thread: https://bitcointalksearch.org/topic/stratum-protocol-documentation-557866 (also linked in my sig)
The wiki version includes the no so-nice hash hack that is a major security issue for miners
Why do we send mining.set_difficulty in this case? Only to show the client we support this method?
Right.And I can't think of any use case of the mining.set_difficulty subscription id. What was the original idea behind it?
Basically every subscription would get an id so you could unsubscribe from them.In this case the default difficulty is 1 until the server sets a higher one, right?
Right. And the changes only take effect for notifys after it.In the end wouldn't it make much more sense to set the difficulty per worker if we already support multiple workers per connection?
Yes, the stratum mining protocol is quite poorly designed.
Yes, I had a look at the wiki.
Why do we send mining.set_difficulty in this case? Only to show the client we support this method?
I saw other examples that don't do it, only send back mining.notify. I guess the mining.notify subscription id is useful to resume the connection if it drops (I can't find now the method used by the client to do so, but I'm sure I saw it once).
And I can't think of any use case of the mining.set_difficulty subscription id. What was the original idea behind it?
In this case the default difficulty is 1 until the server sets a higher one, right?
In the end wouldn't it make much more sense to set the difficulty per worker if we already support multiple workers per connection?
The first one is only in mining.subscribe, and is a subscription id - just ignore it.
Target is not supported by anything for mining.set_difficulty, as far as I know.
Target is not supported by anything for mining.set_difficulty, as far as I know.
Why do we send mining.set_difficulty in this case? Only to show the client we support this method?
I saw other examples that don't do it, only send back mining.notify. I guess the mining.notify subscription id is useful to resume the connection if it drops (I can't find now the method used by the client to do so, but I'm sure I saw it once).
And I can't think of any use case of the mining.set_difficulty subscription id. What was the original idea behind it?
In this case the default difficulty is 1 until the server sets a higher one, right?
In the end wouldn't it make much more sense to set the difficulty per worker if we already support multiple workers per connection?
I have a question about the mining.set_difficult method.
In the example here https://mining.bitcoin.cz/help/#!/manual/stratum-protocol
the first time the parameter here is a string (I would say it's the target), but the second time its a number.
Is it supposed to be a string only if it's a result to mining.subscribe or should the client handle both?
The first one is only in mining.subscribe, and is a subscription id - just ignore it.In the example here https://mining.bitcoin.cz/help/#!/manual/stratum-protocol
the first time the parameter here is a string (I would say it's the target), but the second time its a number.
Is it supposed to be a string only if it's a result to mining.subscribe or should the client handle both?
Target is not supported by anything for mining.set_difficulty, as far as I know.
Another question is about the result to mining.subscribe. Can the result have an arbitrary number of [method, params] pairs or am I missing it completely?
Yes, an arbitrary number is possible.Have you read https://en.bitcoin.it/wiki/Stratum_mining_protocol ?
I have a question about the mining.set_difficult method.
In the example here https://mining.bitcoin.cz/help/#!/manual/stratum-protocol
the first time the parameter here is a string (I would say it's the target), but the second time its a number.
Is it supposed to be a string only if it's a result to mining.subscribe or should the client handle both?
Another question is about the result to mining.subscribe. Can the result have an arbitrary number of [method, params] pairs or am I missing it completely?
In the example here https://mining.bitcoin.cz/help/#!/manual/stratum-protocol
the first time the parameter here is a string (I would say it's the target), but the second time its a number.
Is it supposed to be a string only if it's a result to mining.subscribe or should the client handle both?
Another question is about the result to mining.subscribe. Can the result have an arbitrary number of [method, params] pairs or am I missing it completely?
Unfortunately there's not much point taking notice of that.
Luke-Jr wont allow corrections to his mistakes there.
Luke-Jr wont allow corrections to his mistakes there.
Jump to: