|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 04:37:40 AM |
|
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 04:53:06 AM |
|
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 18, 2015, 05:39:20 AM |
|
Unfortunately there's not much point taking notice of that. Luke-Jr wont allow corrections to his mistakes there.
|
|
|
|
bernardk
Newbie
Offline
Activity: 19
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 16, 2015, 11:07:54 AM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 16, 2015, 11:31:46 AM |
|
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
Newbie
Offline
Activity: 19
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 16, 2015, 12:58:25 PM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 16, 2015, 01:21:23 PM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 16, 2015, 07:26:38 PM Last edit: December 16, 2015, 08:05:26 PM by 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 16, 2015, 07:34:58 PM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 16, 2015, 08:37:20 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) e.g. as a suggestion ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2015, 01:37:49 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 19, 2015, 01:36:29 PM |
|
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.
|
Mining Software Developer.
|
|
|
loshia
Legendary
Offline
Activity: 1610
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 19, 2015, 03:15:30 PM Last edit: December 19, 2015, 03:29:14 PM by 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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) I like your style though ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) . What a irony dude ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 19, 2015, 05:11:48 PM |
|
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
Jr. Member
Offline
Activity: 95
Merit: 2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2018, 08:04:39 AM |
|
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.0My 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.
|
Improve mining pool share/hash rates with the aiostratum-proxy (https://bitcointalk.org/index.php?topic=3179895) stratum mining proxy.
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 19, 2018, 08:56:13 AM |
|
It's all just Socket.
|
|
|
|
dentalperson
Newbie
Offline
Activity: 2
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 24, 2018, 03:13:07 AM |
|
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
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 24, 2018, 06:07:57 AM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
dentalperson
Newbie
Offline
Activity: 2
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 24, 2018, 06:25:48 AM |
|
Ah, of course, because the pool's reward address is in included in what's being hashed. Thanks.
|
|
|
|
|