Stratum protocol discussion

[Realpra]

I had found this great Stratum wiki here:
http://electrum.orain.org/wiki/Stratum_protocol_specification

Now when I go to that link it redirects me to the pornhub web site I kid you not - what gives? Sabotage?

For all the talk of documentation in posts / anywhere I'm having trouble finding out how this works and the expected syntax for commands.
Can anyone help with this problem for instance:
http://bitcoin.stackexchange.com/questions/40556/how-do-i-get-merkle-branches-using-the-stratum-protocol

[1714151236]

1714151236

[1714151236]

1714151236

[kano]

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

[Luke-Jr]

https://en.bitcoin.it/wiki/Stratum_mining_protocol

[kano]

https://en.bitcoin.it/wiki/Stratum_mining_protocol

Unfortunately there's not much point taking notice of that.
Luke-Jr wont allow corrections to his mistakes there.

[bernardk]

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?

[Luke-Jr]

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.
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 ?

[bernardk]

Yes, I had a look at the wiki.

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.

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?

[Luke-Jr]

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.

[kano]

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://bitcointalk.org/index.php?topic=557866.0 (also linked in my sig)
The wiki version includes the no so-nice hash hack that is a major security issue for miners

[macbook-air]

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

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.

[kano]

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)

[Luke-Jr]

The wiki version includes the no so-nice hash hack that is a major security issue for miners

What are you talking about here?

[bitsolutions]

The wiki version includes the no so-nice hash hack that is a major security issue for miners

What are you talking about here?

Pretty sure he's talking about the mining.extranonce.subscribe extension.

[loshia]

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

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.

Come on same network big farm even 5 usd China switch can handle that. I am  sure that you have even cheaper ones laying arround 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

[Luke-Jr]

The wiki version includes the no so-nice hash hack that is a major security issue for miners

What are you talking about here?

Pretty sure he's talking about the mining.extranonce.subscribe extension.

I meant in terms of security issue. mining.extranonce.subscribe is not in itself one, at least in theory.

[wetblanket]

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.

[kano]

It's all just Socket.

[dentalperson]

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?

[kano]

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.
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

[dentalperson]

Ah, of course, because the pool's reward address is in included in what's being hashed.  Thanks.