All servers are updated on EMC.  I'll be curious to see how it works.

Wow, you can even lie to yourself and believe it.  You are truly a marvel density... I bet there are naked singularities somewhere in the cosmos jealous of you.

Comedy gold right here.  Yes folks, watch CreativeX as he back pedals all flustered and distraught because he can't even maintain is own line of BS for more than 2 posts at a time.  This shit writes itself!

Glad you found the quote by the way, thanks for proving that you lied... again (and again, and again, and again, and again, etc...)

Haha thanks for proving me right CreativeX.  You know you just lied and now your response is: "Nuh uh!  I'm not going to do your work for you.  Herp Derp!" 

Yep, a liar through and through!  Good work and thanks for making my job easy, Sparky! 

PS - I looked at the forum you linked, it looks like a bunch of BS to me... and according to you, I know BS, so what's that say?  Yeah, hows that transparency working out for you?  Got your bASIC yet?  How much power will it use?  When is it shipping?  What is the board design? Do you know anything about it other than "Yeah, we are in the design process! I'll let you know soon."   Oh... sorry, did I just hit a sore subject?

Are you sure it's not an issue of share leakage?

Yeah, lets look at the "Plain English" that BTCFPGA is using:

"Ready to ship!"  ... but not really, we actually mean "when our devices are done and we actually have something, we will be ready to ship."
"Shipping the week after Thanksgiving" ... but not really, we actually mean "The first week of December cause we can't read calendars." (OOps, maybe not, we don't know when we are shipping yet!)
"We have a prototype!" ... but you can't see it!
"Our power will be competitive!" ... but we won't tell you what it is!
"Power of two!  Powers of two!" ... MmmmFPHpHMMpHPhp (translation: We just made this shit up to distract from the fact that we have nothing else to offer)
"We are using Molex!  No Barrel!  No BOTH!" ... but we don't know how much power it will consume or if the Molex/Barrel/PCIe will actually be able to handle the current.
"I will have an update today!" ... for definitions of "today" that span a week.
"Make your decision Tuesday!" ... but I won't give you any information to base your decision on TODAY! SUCKA!
My personal favorite:
"72 GH/s! Free upgrade!"  ... But we are magically going to make it use the same amount of power as the 54 GH/s unit!  Of course... makes perfect sense.

Yeah... how is that transparency working out for you, BTW?  Freaking joke is what it is.

Wow, I didn't have to look very far to find where you make up facts and lie about it!  You provided it almost immediately... but that's not terribly surprising, since basically everything you post is a lie in one fashion or another.  Thanks for making my job easy.

In before you say "Nuh uh!"  Please provide the link to where I said that.  I know exactly what I said, but I want you to go exploring and find it on your own to show what an idiot you are.

Interesting, thanks for the heads up ckolivas!

What exactly do you want me to do?  Fly to Asia and knock on someones door?  

Let's be realistic here.  I can't very well force someone to give me a date that's accurate, since by forcing them I might be putting them in a position to give me a false date just to get me off their ass... and that helps no one.


Population:  CreativeX

And this, kids, is why Creativex is a failure in life while those around him succeed.  It's why he trolls the Bitcointalk forums, manufacturing "fake" facts to make himself feel better.  I'd pity him if I cared, but I don't.

Callous Inaba is Callous.

Well heck, by that criteria BFL is fine, too... since we've always maintained that we would would target October but it would be as late as December (hence the January 1st refund policy, which has been there since day one.)

Thanks for the confirmation that BFL is on target timeframe wise as well, I appreciate it! 

I love how you completely leave out the part where we have already committed to matching competitors products.  Oh.. but then that would mean you don't have anything to complain about, right?  The only Big Friggin Liar here is you, I'm afraid.

Yes, the intent is to do away with singles.  All of the current singles will be going towards upgrading to a minirig.  The singles are just too much to manage in quantity.

For scenario B, the old difficulty would still apply to work for that discrete issue of work.  I definitely do not want to create a potential scenario where it could be exploited by forcing a difficulty change.  One way can be exploited by pool ops (not accepting work once difficulty changed), one way can be exploited by miners (accepting work for higher difficulty work as valid once work drops) and one way (tying difficulty to work) can not be exploited by either, and this seems the most sane way to handle it. 

Ok, if that's the case then that solves the issue.  Conman, does that resolve the rapid difficulty change issue with EMC then if that particular method is implemented to handle difficulty from the Stratum protocol side of things?


It needs to... not to keep pool ops honest so much as to allow miners to verify that what they THINK is happening is really happening.  It's about empowering the miners, not policing the pool ops.


Is this relevant though?  I'm not sure I'm comfortable with this, as it flips the exploit over to the miners side (although it has much less of an impact).  I don't want to issue difficulty 32 shares, have them reduce their hashrate while they save up a bunch of shares until their difficulty reduces then submit them all as valid.  Again, we go back to difficulty being tied to the work sent out.  Allowing it to "leak" out to other work/difficulty relationships is not the correct way to go about it IMHO.

Ok... I think maybe part of the fundamental problem here is that Slush's view is that all work sent out to a miner is related to work that has come before it (and work that will be sent after it), whereas, at least in my view, work that is sent out is discrete; it's completely immaterial what's come before or what is going to come after.  Correct me if I'm wrong here, but it seems that this is the root of the issue and why difficulty is not tied to work in Stratum.  

Maybe if you (Slush) can explain why a work packet being sent to a miner needs to be related to another work packet (either being sent to the same miner or someone else) as opposed to being discrete?  I'm just not seeing why work at difficulty X needs to be related to work at difficulty X + 1.  The miner is assigned work at difficulty X.  If they do the work, they should be rewarded for that work, regardless of the fact that difficulty changed since the work was sent out... they still did the work!  So rejecting the work because the pool arbitrarily decided to change the difficulty on the miner is rude if not outright dishonest.

Rejecting shares because difficulty changes AFTER the fact could easily be exploited by a malicious pool and amount to a very, very significant income stream at a miners expense.  For example, say I setup a malicious pool... every 10th share, I code the pool to raise the difficulty (then reduce it a short while later), thereby "rejecting" 1 out of every 10 shares that miner sends back... but I keep those shares and assign them to another user or the pool itself, etc... because those shares are still valid.  Now the pool gets 10% of the shares a user sends, the user thinks "crap, I'm getting 10% rejects because of my hashrate" or whatever reason you want to assign to it and it looks totally legitimate.  Now reduce that to .1% and spread that across 100 TH and 2000 miners... the miners won't notice such a small amount, but now the pool op gets the equivalent 100 GH/s for free and no one is the wiser.  This is what the Stratum protocol allows as designed, and if I'm wrong about this please let me know and explain why this can't be done?  This is also why difficulty needs to be tied to the work, so that work performed is never rejected because the pool decided to change the rules after the fact.

A more extreme example would be:  Pool keeps increasing the difficulty every set interval, causing all shares to be discarded by a miner until a valid block share is found.  Now that miner gets credit for 1 share, even though they should have sent 20,000 shares.  Yeah, this is unrealistic, but it illustrates the point that it's possible to exploit the protocol to the detriment of the miner.

I will be happy if I'm wrong and if someone can point out where I'm mistaken.  This is really my only major problem with Stratum at the moment, everything else is fairly minor in comparison.  I apologize if my tone appears aggressive towards you, Slush.  It was not intended to be, beyond my minor irritation with the way Stratum was rolled out... and that irritation is minor and not worth complaining about.  My "bashing" of Stratum is because the problem has been beat to death and you basically ignored anyone who disagreed with the work/difficulty being uncoupled.  Regardless, moving on to the solution you mentioned:

How does it address the following scenario:

Miner is given work at difficulty 2.  Miner begins processing work at difficulty 2 and finds a valid share... while processing the work Stratum sends mining.set_difficulty 3.  

What happens to that share found at difficulty 2, which was valid at the time it was issued?  The miner did the work based on the rules it was given, but the rules got changed after it already agreed to the work.

Fuck Off, really?  That's where we are at now?


You're absolutely right I'm not preparing a proprietary protocol!  I am 100% against doing so, which is what you did and then "opened it up" to the community.  That's what irritates me, but it's a minor irritation which is why I've not made a big long posts about it.  I'm sure you had your reasons and as I said, what's done is done.


Why are you waiting for my proposal if you already have one that fits your needs?  That doesn't even make sense!


I did (https://bitcointalk.org/index.php?topic=108533.msg1344256#msg1344256).  You did not respond, so what do you want me to do, pitch a fit in the thread?


I don't know what you mean by this so it's hard to respond.  Ok, the protocol doesn't define a window, fair enough.  However, because the protocol fails to tie the difficulty to the work, some pools are putting in a window to fix the broken protocol and solve an issue that should not even be an issue.  If the difficulty were tied to the work, as it should be, it would be completely irrelevant when the share is sent back (so long as it's not expired) when viewed in relation to the current work being sent out at a higher difficulty.  

From your responses in that thread, you seem to think it is ok to discard valid work simply because the difficulty rises in the middle of a nonce.  That is basically robbing the miners of valid work and it's not something I am willing to do to my miners.  Yes, absolutely, I agree that it's a very small amount of shares, but the cumulative discards of perfectly valid shares is not insubstantial.  And this is all because difficulty is not tied to work.  Tie difficulty to work and this problem goes away.


I did not say there were any bottlenecks in Stratum, but your response further lends credence to the fact that I don't think you understand the scale of what is about to be unleashed upon the mining world.  You are still thinking in the old mining terms were 100 TH is virtually inconceivable (Given that the whole network is a fraction of that right now).  Within less than a year, 100 TH will be well within the reach of modest professional miners and I will not be surprised to see the largest miners wielding a significant fraction of a PH.  But this isn't really a Stratum issue, beyond the fact that the discarded shares will scale in a linear fashion with the hashrate and miners will be losing a non-trivial amount of shares for no reason when mining with Stratum on current implementations.


See above.  The difficulty windows are in response to fact that Stratum does not properly tie difficulty to work.


Again, see above. To overcome the flaw in the protocol, apparently the solution BTCGuild and OzCoin have come up with is to make a large hysteresis window to prevent frequent difficulty changes and to minimize the impact of lost shares.  That's a kludge to fix a problem that shouldn't exist, which is directly caused by the protocol specification.


Ok, fair enough.  Maybe Con can chime in then and tell me what the difference is between EMC and Slush's pool as viewed by CGMiner?  All this is ultimately due to CGMiner apparently having trouble with EMC because the difficulty changes too rapidly - but if that's the case, wouldn't the same problem be evident on Slush's pool?  If not, why not?  I'll be glad to fix it if there's a problem somewhere.


What?  Of course there is!  Tie difficulty to the work sent out.  When the work is returned, compare it to the difficulty sent out, if it's under the target you're good to go, if not, reject it.  Simple, easy, obvious and straight forward.  I know you are aware of this, since it's been brought to your attention several times by several different people.  So I'm confused on what you are trying to say here?


Umm, my tone?  What are you talking about?  I made a comment in this thread, about CGMiner, explaining why Stratum is not correct and you come back at me with Fuck Off because I answered your question.  The problem with Stratum has already been beat to death in the other thread, so why should I go there and beat that dead horse again?  You clearly do NOT want to tie difficulty to the work in Stratum, as you've stated numerous times.  

Argh, there doesn't seem to be a way to make everyone happy.

I'm thinking maybe I should sell off the singles and payout the final payment on the singles for the sale price and then let people buy back in to RIG as appropriate.  That would fulfill the contract as stated and should satisfy people in a fair (if not ideal) manner.  What are the thoughts on this?

With regards to being aggressive, I am irritated with the Stratum protocol in general.  It was developed in secret and foisted upon the mining world as the second coming of mining.  That's all well and good, but it was flawed and basically every single problem we've run into so far with it would have been fixed if it was developed in the open with input from the pool operators.  Instead, I'm stuck having to implement a broken protocol and make changes/fixes as the protocol is fixed in a manner that should have happened from the start... so yes, it's very irritating.  But what's done is done and I have not posted much in that thread because there's no sense in bitching about it; it is what it is.

Personally, I don't care what solution I use to solve the problems my pool is facing, so long as it works and doesn't cause problems down the road like GW has (but who can blame Tycho et al for GW since nobody really saw this scale of mining back then).  I digress... the current implementation other pools (IE - pools that are not EMC) have with Stratum is the hysterisis methods being employed are there to fix the (former?) problem with Stratum decoupling the difficulty from the work.  There is absolutely no compelling reason to make a large window of fluctuating difficulty, other than the fact that if you don't (on Stratum) shares are incorrectly discarded.  It's not like it requires a large amount of additional work on the miner end to have difficulty changing with every submission or anything.  Additionally, changing difficulty more often alleviates future problems with fluctuating hashrates. 

That said, it's something I wanted to bring up at some point:  I don't think you (Slush) or any of the other pool ops quite understand what's about to happen with regards to ASICs.  With these large difficulty windows, you are going to get flooded with shares as large scale miners come on and offline.  Even with Gen1 ASICs, the problem is going to be a bit pronounced on the larger pools as multi terahash miners come and go.  With Gen2, Gen3, and so on into the future, the problem will only magnify to unmanageable levels.  Waiting to change difficulty for longer than is necessary will only serve to flood your server with unnecessary work returns, increasing your load and potential points of failure.  Stop and consider what happens when 250 TH across 20 workers decides to hop on and off your pool... or even better yet, what if you get someone in control of 500 TH that decides to screw with your pool by hopping on and off your pool in a manner that will keep the difficulty lower than it should be?  This is going to be a problem, either through malicious acts or through random chance - it's why I do not allow user selected difficulty on EMC and why I have difficulty changing fairly rapidly.  I don't want to get DoS'd either through intention or not simply because I have 500 TH submitting difficulty 32 shares for 5 minutes before they get bumped up, rinse and repeat.  There is no drawback to rapid difficulty change in the ASIC era, and artificially limiting that to accommodate a problem with the protocol instead of fixing the protocol is backwards thinking.

I'll review the changes you mentioned... from a cursory glance, it doesn't seem to address what happens when a worker submits a share from a previous work block that had a lower difficulty or does it?  Your post is a little unclear on that, so if you could clarify that, it would help and I will work to get that incorporated in EMC. 

Assuming that addresses the fundamental issue of a miner submitting a lower difficulty share that is still valid after the difficulty has increased, does that address the problems CGMiner is having with EMC and it's rapid difficulty changes, Con?   If not, can you elaborate on exactly what the problem is with CGMiner and EMC over Stratum?

"Everone invloved" would be Conman, Kano, Luke, Slush, myself and pretty much anyone who has anything to do with development and implementation of Stratum.  What is your authority to make a claim?

Of course you aren't seeing the poof, because it shows up as a rejected share when it shouldn't be.  But how would you know?