what are the technicals what does this mean though, difficulty-1?
https://en.bitcoin.it/wiki/Difficulty
well if I make difficulty-5000000000 woudln'ti make much more bitcoins than everyone
Topic: [ANN] Stratum mining protocol - ASIC ready - page 29. (Read 146229 times)
https://en.bitcoin.it/wiki/Difficulty
well if I make difficulty-5000000000 woudln'ti make much more bitcoins than everyone
what are the technicals what does this mean though, difficulty-1?
https://en.bitcoin.it/wiki/Difficulty
Surprising that mining has not yet moved away from difficulty-1 mining.
what is the significance?
Same payout, less server <-> miner traffic.
what are the technicals what does this mean though, difficulty-1?
Surprising that mining has not yet moved away from difficulty-1 mining.
what is the significance?
Same payout, less server <-> miner traffic.
Surprising that mining has not yet moved away from difficulty-1 mining.
what is the significance?
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
Does that indicate you won't be copying ("merging") ckolivas' stratum code into your spork?
or
Will you'll be developing your own code or waiting for someone else to copy ("merge") from?
As I said before, if someone else writes the code, I will (probably - ie, if the code is reasonable) merge it into BFGMiner.
Con is capable of producing reasonable code, so I expect that when he finishes it, I will accept it into BFGMiner.
The code will be more than reasonable, the problem for you will be how 'unreasonable' you make it after you copy it and if you can even implement it in your cgminer clone.
Since you've already made it pretty clear that it's too difficult for you to do - it's been obvious for a while you'll just copy it from cgminer
Like most of the internals of cgminer, your clone is certainly no better, due to the fact that you copy the code directly from cgminer, but often worse, due to the changes you've made without any guidance or feedback ... that you seriously need ... (you also clearly have issues when it comes to software performance)
Even your statement above, about my comment regarding the Stratum protocol, proves you can't see past your own shallow understanding of something and realise that you do not know everything and your know-it-all attitude is your own downfall since you clearly do NOT know-it-all.
It is not a stupid change suggestion, and it is quite easy to see that it produces an unnecessary implementation issue - a clear timing issue due to the fact the information has been separated - this yet again shows how severely unable you are to test code properly - since the problem is quite apparent as soon as you understand that no code takes 'zero' time to execute (as you once argued with me about code that you said does take zero time to execute
) and worse as soon as a network delay is added to the issue it make it many times worse. 
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
Does that indicate you won't be copying ("merging") ckolivas' stratum code into your spork?
or
Will you'll be developing your own code or waiting for someone else to copy ("merge") from?
As I said before, if someone else writes the code, I will (probably - ie, if the code is reasonable) merge it into BFGMiner.
Con is capable of producing reasonable code, so I expect that when he finishes it, I will accept it into BFGMiner.
It will be interesting to see how you alter his code when you copy it into your cgmerge branch to suit your needs.
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
Does that indicate you won't be copying ("merging") ckolivas' stratum code into your spork?
or
Will you'll be developing your own code or waiting for someone else to copy ("merge") from?
As I said before, if someone else writes the code, I will (probably - ie, if the code is reasonable) merge it into BFGMiner.
Con is capable of producing reasonable code, so I expect that when he finishes it, I will accept it into BFGMiner.
It will be interesting to see how you alter his code when you copy it into your cgmerge branch to suit your needs.
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
Does that indicate you won't be copying ("merging") ckolivas' stratum code into your spork?
or
Will you'll be developing your own code or waiting for someone else to copy ("merge") from?
As I said before, if someone else writes the code, I will (probably - ie, if the code is reasonable) merge it into BFGMiner.
Con is capable of producing reasonable code, so I expect that when he finishes it, I will accept it into BFGMiner.
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
Does that indicate you won't be copying ("merging") ckolivas' stratum code into your spork?
or
Will you'll be developing your own code or waiting for someone else to copy ("merge") from?
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
Well - that immediately means it must be defcon 4 critical if you don't think it's necessary 
P.S. ckolivas doesn't care about this - he ignored me
To be fair, I had exactly the same discussion with Eleuthria but I had bigger fish to fry and stopped caring about it. He or slush can come and defend why they think it's ok. I'll work around the protocol whatever it is.
I wouldn't care about it either. If one is implementing Stratum in the first place, including difficulty in each job really doesn't help any.
Meanwhile ...
I think there is a change needed to the protocol ... interested in your opinion.
Suggestion: you should completely remove "mining.set_difficulty" and put difficulty in "mining.notify"
The main issue I see is that it overly complicates handling difficulty by posing issues that need to be handled due to having information in 2 messages
The only argument I've heard so far for having it separate is that is saves some bytes per "notify" - but the whole argument about stratum is that you don't need to send data very often - so who cares if you save ~1kbyte an hour per worker? ...
(less than 20 bytes x 1 "notify" per minute)
... and difficulty changes (requiring a whole new "notify") would not be an overhead since you would simply send the new difficulty change as part of the next "notify" as per normal (I can think of no urgency to send a difficulty change before the next notify)
"set_difficulty" seems to represents a work restart in exactly the same way as a "notify" does.
In fact it seems to be similar (but not the same) level as a "notify" with "Clean Jobs"=true
Any work you are working on is no longer based on the definition when the work was started
If the difficulty actually went down, you may end up throwing away work that is now valid since the pool will accept the lower difficulty work at the time is sends out the "set_difficulty" but the miner has to deal with receiving and processing that before it will allow the lower difficulty work
If the difficulty went up then your work that was valid at the time it was started may no longer be valid, even though only a "Clean Jobs"=true (i.e. an LP) should make the work invalid
This will also mean an issue in the miner that may have been over looked so far?:
The code that deals with checking the difficulty must all be exclusively thread locked since the difficulty is not at the work level, it is at a global level (with current "getwork", difficulty is a direct attribute of the work)
Also, how is this handled at the pool?
It certainly represents a loss of any lower difficulty work that was sent to the pool after the pool has sent the "set_difficulty"
(remember, pool<->miner is not instant ... in fact it is quite a long time when counting hashes ...)
The problem I see is that, having them as 2 different messages means it depends on the pool implementation as well as the miner implementation what will actually happen, when a "set_difficulty" is sent. It also complicates that process unnecessarily for no real gain.
P.S. ckolivas doesn't care about this - he ignored me
I think there is a change needed to the protocol ... interested in your opinion.
Suggestion: you should completely remove "mining.set_difficulty" and put difficulty in "mining.notify"
The main issue I see is that it overly complicates handling difficulty by posing issues that need to be handled due to having information in 2 messages
The only argument I've heard so far for having it separate is that is saves some bytes per "notify" - but the whole argument about stratum is that you don't need to send data very often - so who cares if you save ~1kbyte an hour per worker? ...
(less than 20 bytes x 1 "notify" per minute)
... and difficulty changes (requiring a whole new "notify") would not be an overhead since you would simply send the new difficulty change as part of the next "notify" as per normal (I can think of no urgency to send a difficulty change before the next notify)
"set_difficulty" seems to represents a work restart in exactly the same way as a "notify" does.
In fact it seems to be similar (but not the same) level as a "notify" with "Clean Jobs"=true
Any work you are working on is no longer based on the definition when the work was started
If the difficulty actually went down, you may end up throwing away work that is now valid since the pool will accept the lower difficulty work at the time is sends out the "set_difficulty" but the miner has to deal with receiving and processing that before it will allow the lower difficulty work
If the difficulty went up then your work that was valid at the time it was started may no longer be valid, even though only a "Clean Jobs"=true (i.e. an LP) should make the work invalid
This will also mean an issue in the miner that may have been over looked so far?:
The code that deals with checking the difficulty must all be exclusively thread locked since the difficulty is not at the work level, it is at a global level (with current "getwork", difficulty is a direct attribute of the work)
Also, how is this handled at the pool?
It certainly represents a loss of any lower difficulty work that was sent to the pool after the pool has sent the "set_difficulty"
(remember, pool<->miner is not instant ... in fact it is quite a long time when counting hashes ...)
The problem I see is that, having them as 2 different messages means it depends on the pool implementation as well as the miner implementation what will actually happen, when a "set_difficulty" is sent. It also complicates that process unnecessarily for no real gain.
P.S. ckolivas doesn't care about this - he ignored me
It doesn't mean stratum is a bad thing, it's just a shame that I put a lot of work into making cgminer scale to massive workloads pool overloads and I have to implement something else from scratch again.
Let me fix it for you ;-P.
Quote
[02:36] <@conman> stratum is basically orthogonal to all the hard work I put into network scheduling D:
Quote
[02:36] <@conman> stratum is basically orthogonal to all the hard work I put into network scheduling D:
I just succesfully tested mining over Tor using Stratum proxy + torify (package torsocks).
# torify ./mining_proxy.py -o pool57wkuu5yuhzb.onion
Console shows some warnings, but it works nicely. Of course direct connection has much lower latency, but for people with concern in anonymity, Tor + Stratum proxy should be a good choice.
Momchil reported that latest poclbm with native Stratum support mining over Tor as well, but you must specify stratum:// directly to let it work properly.
# torify ./mining_proxy.py -o pool57wkuu5yuhzb.onion
Console shows some warnings, but it works nicely. Of course direct connection has much lower latency, but for people with concern in anonymity, Tor + Stratum proxy should be a good choice.
Momchil reported that latest poclbm with native Stratum support mining over Tor as well, but you must specify stratum://
Yes. With the newer version 8.2 the BAMT rigs are now happy campers.
Using 0.8.3 and yes happy campers
Jump to: