dhsc19
Member
Offline
Activity: 96
Merit: 10
|
|
April 25, 2014, 07:39:42 PM |
|
From what it looks like Nicehash made a smart business decision and it had nothing to do with just getting a solution, but rather with who they decide to do business with. There are certain players you don't want on your team and you can tell right away.
|
|
|
|
comeonalready
|
|
April 25, 2014, 07:41:50 PM Last edit: April 25, 2014, 08:08:32 PM by comeonalready |
|
suchmoon, I don't know who you are yet. But do you really want someone like me looking into it? Think about that before answering and act accordingly. So much butthurt over 1 BTC
And I only asked for 0.25 BTC, so obviously money has nothing to do with it. That would not even buy a decent dinner out where I live. This is purely about principle.
|
|
|
|
phzi
|
|
April 25, 2014, 08:25:22 PM |
|
Lol... sometimes it is good to give back. I have made plenty of profit from the various dev's that have built c/sgminer, and if I can patch an annoying bug with a single line, I would prefer to honor the open source nature of the crypto communities by sharing my fix. If someone wants to pay (or tip) me for the time it took to debug this, I will be appreciative. But I don't see the need to demand compensation.
I am happy, on principle, to have offered this freely.
|
|
|
|
comeonalready
|
|
April 25, 2014, 09:48:37 PM Last edit: April 25, 2014, 10:21:56 PM by comeonalready |
|
Lol... sometimes it is good to give back. I have made plenty of profit from the various dev's that have built c/sgminer, and if I can patch an annoying bug with a single line, I would prefer to honor the open source nature of the crypto communities by sharing my fix. If someone wants to pay (or tip) me for the time it took to debug this, I will be appreciative. But I don't see the need to demand compensation.
I am happy, on principle, to have offered this freely.
If that were really true, then you would have given your hacky patch away freely four days ago when you had it, but instead you made a point to tell everyone you that had it but refused to share as it was giving you an advantage -- in essence gloating and holding it out over everyone. And you are only making this statement now to save face in what you have since likely realized was a poor decision to disclose, and now begging for tips for doing so. Say what you want about me, but I am direct in my approach. You are transparent in your attempts to manipulate, but I would bet that you don't even know you're even doing it. My patch is hacky and I don't plan to publish it. Besides, right now it is giving me an advantage... why would I share when you have made this system competitive instead of fair/proportional?
And by the way, yours is not a comprehensive fix, as I nearly certain that you already know as you called it hacky. As you were so concerned earlier about how changing extranonce1 requires the briefest interruption in mining to reconnect stratum, how do you feel that your patch requires some mining downtime too, however minimal, though longer than former extranonce1 issue?
|
|
|
|
TheMathGuy
Newbie
Offline
Activity: 26
Merit: 0
|
|
April 25, 2014, 10:27:46 PM |
|
@comeonalready
Please stop cluttering the thread with your greediness over 0.25BTC. If you're not a fan of open source than this is clearly the wrong community for you, go work for M$ or something.
@phzi
Thanks a million for the fix, i will donate some ^^
EDIT: Could you pm me your BTC or LTC adress?
|
|
|
|
zneww
|
|
April 25, 2014, 10:34:10 PM |
|
comeonalready's name just explains him perfectly.
|
|
|
|
dhsc19
Member
Offline
Activity: 96
Merit: 10
|
|
April 25, 2014, 10:39:22 PM |
|
It is totally possible that phzi may have started off with selfish motivations in the start, but obviously he had an epiphany of generosity. The fact that someone could change their mind to decide to do the more generous thing speaks far more of character than to be a flat out bully: suchmoon, I don't know who you are yet. But do you really want someone like me looking into it? Think about that before answering and act accordingly.
Then to try to appeal to the morality (which is incredibly passive-aggressive AND manipulative): And I only asked for 0.25 BTC, so obviously money has nothing to do with it. That would not even buy a decent dinner out where I live. This is purely about principle.
All this sense of entitlement all over something that one was never entitled to in the first place. So, you made an offer and the offer was refused. At that point nothing was ever given, nothing was yours. Therefore, nobody took anything away from you...which is what you seem to want people to think...that something that was rightfully yours was taken away from you. The behavior being displayed now shows a severe lack of maturity and somewhat sociopathic tendencies. I find it interesting that people who play "the game" with the whole "You're losing money every day, pay me now for only a fraction of the cost...I'm the only savior you have" call everyone else manipulators when they themselves get out-played. Phzi would be no more of a manipulator than what you would be if you had "won the prize" instead. So, trying defame everyone else's reputation when you yourself engage in the same thing is hypocritical and only solidifies the conclusion that most people have probably come up by now about your personality and character. I'm guessing there might be a hint of alcoholism or substance abuse going on. Its actually quite to the benefit of this service and community that Nicehashdev decided not to work with you. Childish tantrum is something NiceHash service is well off to do without.
|
|
|
|
hutnik
Member
Offline
Activity: 95
Merit: 10
|
|
April 25, 2014, 10:51:22 PM |
|
Cmon, you can settle this in PM, or make separate thread for your lovestory.
|
|
|
|
nicehashdev
|
|
April 25, 2014, 11:46:31 PM |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher
|
|
|
|
elpsycongro
|
|
April 26, 2014, 11:14:07 AM |
|
Back on topic, Nicehash, what happened to all the high paying jobs? Let's get those rolling again! I need to ROI before Titan etc lands!
well its even lower now ... on on top of that there are almost no jobs left !
|
|
|
|
pieran
Newbie
Offline
Activity: 34
Merit: 0
|
|
April 26, 2014, 01:52:58 PM |
|
Back on topic, Nicehash, what happened to all the high paying jobs? Let's get those rolling again! I need to ROI before Titan etc lands!
well its even lower now ... on on top of that there are almost no jobs left ! The prices on Nicehash are similar (or a bit less) than the average on big pools like waffle or clever because I think people mostly buy hash power here to direct it to some multipools. Last week was the "Whitecoin" hype which raised the earnings per MHash drastically but unfortunately this was just a short blast.... When the Scryt ASICS hit the market I think the only profitable (GPU mined) coins will be scrypt-n and X11 (although both are not really asic resistant in the long run). I am really thinking about starting to turn away from Scrypt to e.g. Hiro and Darkcoin though the earnings are even less than scrypt. And there is a fair chance that these coins raise in value as soon as more people start to "switch their rigs" to them. Furthermore the summer is coming here in Germany and X11 extensively lowers the temperature of my basement :-) Does it make sense to switch now if you do not need the quick ROI?
|
|
|
|
Pfool
|
|
April 26, 2014, 07:41:57 PM |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher First of all, thank you for the fixes. The "no more reconnects when switching orders" fix seems to work for me (I can see several "PoolName extranonce change requested" in sgminer). But when I use a specific pool, sgminer immediatly returns to the shell (on Linux). It works with this pool when I use the "--no-extranonce-subscribe" option. The pool return the following response when it receives an unknown command (the mining.extranonce.subscribe one): {"error": "Unrecognized request provided", "id": 0, "result": false}. I think the "error" parameter value is not a valid JSON-RPC format. Maybe it's the cause of the crash of sgminer. For the idle bug, I do not use the p=xxx parameter so I can't say.
|
Thanx BTC: 19wv8FQKv3NkwTdzBCQn1AGsb9ghqBPWXi
|
|
|
qbitx
Newbie
Offline
Activity: 34
Merit: 0
|
|
April 27, 2014, 12:46:25 AM |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher I tried your fixed version, and after ~8 hours it started acting up. Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while. I don't think the idle bug is fixed.
|
|
|
|
phzi
|
|
April 27, 2014, 01:00:58 AM |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher I tried your fixed version, and after ~8 hours it started acting up. Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while. I don't think the idle bug is fixed. I am fairly sure the idle bug is fixed, but I have heard the extranonce stuff seems possibly unstable. If you're using the bitbandi/sgminer code, then the included fix is a bit different - https://github.com/bitbandi/sgminer/commit/77545de0e8b0d0a6e57cf518920de5e6b818e290 . You won't want to be using pool->idle = true; AND this commit. Closing the stratum connection like in that commit causes pool->stratum_active = pool->stratum_notify = false (but does not affect pool->idle). I can't say if this works, as I haven't tested it myself. But, from my read thru of the code, the program flow will be quite different then my patch, and I was marking the pool idle instead of suspending stratum for a reason.
|
|
|
|
qbitx
Newbie
Offline
Activity: 34
Merit: 0
|
|
April 27, 2014, 01:23:33 AM |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher I tried your fixed version, and after ~8 hours it started acting up. Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while. I don't think the idle bug is fixed. I am fairly sure the idle bug is fixed, but I have heard the extranonce stuff seems possibly unstable. If you're using the bitbandi/sgminer code, then the included fix is a bit different - https://github.com/bitbandi/sgminer/commit/77545de0e8b0d0a6e57cf518920de5e6b818e290 . You won't want to be using pool->idle = true; AND this commit. Closing the stratum connection like in that commit causes pool->stratum_active = pool->stratum_notify = false (but does not affect pool->idle). I can't say if this works, as I haven't tested it myself. But, from my read thru of the code, the program flow will be quite different then my patch, and I was marking the pool idle instead of suspending stratum for a reason. Ah, alright. Well that was my poor judgement just blindly adding in the pool->idle = true; in addition to the suspending pool thing. I'll try to debug the issue further if it occurs again - the issue is that it takes so damn long to trigger
|
|
|
|
comeonalready
|
|
April 27, 2014, 04:38:44 AM Last edit: April 27, 2014, 10:52:32 AM by comeonalready |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher I tried your fixed version, and after ~8 hours it started acting up. Then, I added in 'phzi's pool->idle = true; fix as well into the code - and it still started screwing up after a while. I don't think the idle bug is fixed. I am fairly sure the idle bug is fixed, but I have heard the extranonce stuff seems possibly unstable. If you're using the bitbandi/sgminer code, then the included fix is a bit different - https://github.com/bitbandi/sgminer/commit/77545de0e8b0d0a6e57cf518920de5e6b818e290 . You won't want to be using pool->idle = true; AND this commit. Closing the stratum connection like in that commit causes pool->stratum_active = pool->stratum_notify = false (but does not affect pool->idle). I can't say if this works, as I haven't tested it myself. But, from my read thru of the code, the program flow will be quite different then my patch, and I was marking the pool idle instead of suspending stratum for a reason. Ah, alright. Well that was my poor judgement just blindly adding in the pool->idle = true; in addition to the suspending pool thing. I'll try to debug the issue further if it occurs again - the issue is that it takes so damn long to trigger That is because neither phzi nor ebandi implemented a proper idle bug fix. They addressed the symptom but not the cause. Also, ebandi is missing an important piece of a fully backwards compatible extranonce subscription implementation. Currently, it is unstable universally (i.e. works fine at nicehash but will break unexpectedly at other pools). I know why that is happening too, but keep working on it though. You'll get there eventually.
|
|
|
|
nicehashdev
|
|
April 27, 2014, 11:38:49 AM |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher First of all, thank you for the fixes. The "no more reconnects when switching orders" fix seems to work for me (I can see several "PoolName extranonce change requested" in sgminer). But when I use a specific pool, sgminer immediatly returns to the shell (on Linux). It works with this pool when I use the "--no-extranonce-subscribe" option. The pool return the following response when it receives an unknown command (the mining.extranonce.subscribe one): {"error": "Unrecognized request provided", "id": 0, "result": false}. I think the "error" parameter value is not a valid JSON-RPC format. Maybe it's the cause of the crash of sgminer. For the idle bug, I do not use the p=xxx parameter so I can't say. Hello, can you share with us the name of the pool that reports incorrect msg back, so we can perform tests against it. Does crash happen when your miner tries to connect/subscribe/auth to it?
|
|
|
|
nicehashdev
|
|
April 27, 2014, 04:01:20 PM |
|
Some improvements were applied, most noticeable one is: Fair way for paying providers. It does not matter the order your miners work on, your miners are paid average sum, according to how much work (shares) was provided by them each minute.
|
|
|
|
nicehashdev
|
|
April 27, 2014, 04:18:15 PM |
|
Another improvement now after we introduced fair payments for providers: Minimal limited hashpower is now 0.05 GH/s -> 50 MH/s.
|
|
|
|
Pfool
|
|
April 27, 2014, 04:36:31 PM |
|
Whoever is capable of compiling own sgminer, please test this version: https://github.com/bitbandi/sgminer/It contains two fixes: - idlebug fix - support for extranonce subscription - no more reconnects when switching orders -> your hashrate on NiceHash will be higher First of all, thank you for the fixes. The "no more reconnects when switching orders" fix seems to work for me (I can see several "PoolName extranonce change requested" in sgminer). But when I use a specific pool, sgminer immediatly returns to the shell (on Linux). It works with this pool when I use the "--no-extranonce-subscribe" option. The pool return the following response when it receives an unknown command (the mining.extranonce.subscribe one): {"error": "Unrecognized request provided", "id": 0, "result": false}. I think the "error" parameter value is not a valid JSON-RPC format. Maybe it's the cause of the crash of sgminer. For the idle bug, I do not use the p=xxx parameter so I can't say. Hello, can you share with us the name of the pool that reports incorrect msg back, so we can perform tests against it. Does crash happen when your miner tries to connect/subscribe/auth to it? Just sent you a PM with the pool name. The crash happens just after the startup of sgminer. The offending pool is one of my backup pool, but sgminer seems to check if the pool is Alive at startup. The crash happens just after the response to the mining.extranonce.subscribe request from this pool. (here after is the response {"error": "Unrecognized request provided", "id": 0, "result": false}). If I remove the pool from the backup, sgminer works fine.
|
Thanx BTC: 19wv8FQKv3NkwTdzBCQn1AGsb9ghqBPWXi
|
|
|
|