 Show Posts
|
|
Pages: [1] 2 3 4 »
|
And for future note, I'm going to treat all future bugs like this: If you're not using Eligius, it is not my problem.
You probably shouldn't advertise multipool support, then.  |
|
|
|
|
It was still 31% on central and now it's 45% on west. Nothing changed over here, either.
|
|
|
|
|
30% reject rate on your new central server. Nice!
|
|
|
|
Exception in thread "DiabloMiner GetWorkAsync for 127.0.0.1" java.lang.NullPointerException
at com.diablominer.DiabloMiner.DiabloMiner$NetworkState.doJSONRPC(DiabloMiner.java:684)
There is a missing null check on xRollNTime at line 681. Just make it look like the following: if(xRollNTime != null && !"n".equalsIgnoreCase(xRollNTime)) { |
|
|
|
|
Commit 1bcbb3fd85178692941b5e168aecf71e755a3909 slows things down (5870 -v 2 -w 128).
|
|
|
|
|
Nice burp with a 4039% reject rate. Glad it's fixed...
|
|
|
|
Edit: you could also have the 3 big pools connect to each other as well, the block would be sent out through all 3 pools making it nearly impossible to tell which sent it out.
The pools won't delay each other's messages, either. |
|
|
|
That's a horrible analogy, unless you are trying to find some sort of moral equivalent to the "wrongness" of the situation. It's more like playing poker and some people have sunglasses on, but you don't like that.
Nah, it's more like a group of mercenaries signed up to fight a war. However some people disappear every time a battle lasts more than 5 minutes but still get paid like those who slugged it out for the next 8 hours. Yeah, well, delayed stats is kinda like when you go to Burger King and ask for a burger with cheddar cheese, and they say, "You can't have it your way!" So, you say, "Well, I have my OWN cheddar cheese! I'll just put it on top." Then they say, "You can't bring outside food into here!" Yeah, it's kinda like that. |
|
|
|
this all reminds me of people getting upset when others say downloading a movie using bittorrent is stealing
because nothing was taken from anyone else. they still have their copy of the movie.
yet.. anyone with a brain knows it was wrong... even if the word stealing was not quite accurate in the old
fashioned sense.
That's a horrible analogy, unless you are trying to find some sort of moral equivalent to the "wrongness" of the situation. It's more like playing poker and some people have sunglasses on, but you don't like that. same thing here more or less. people want to take advantage of a system that helps them and since it does not
"directly" take anything from others (you got paid for your shares just like i did!!!) they consider it good form. when in
reality they must realize in order for them to get more others have to get less. let the peons solve the long rounds..
i am out of here! rofl! suckers!
The system is "broken". If you don't take advantage, you *are* a sucker... or lazy. well pool hoppers.. the bar has been raised at btcguild. get your code on and defeat the stats delay.
It's not already done? For hopping to be closer to impossible, a lot more work and/or a lot less transparency will need to happen. |
|
|
|
Awe... Somebody needs a nap (as in you). Did someone take your binkey away? Sound's like you are the one having a temper tantrum now that you are no longer getting your way. I bet for you Puberty is a bitch (as in you are still going through it).
How am I not getting my way? If you consider wanting discussion without entitled children who have difficulty with mathematics whining, then yes. I am not getting my way. If you mean that I can't pool hop here, I don't care. I don't pool hop. It's not worth the trouble. I'm sure eleuthria could confirm, if he wanted to waste even more time on this stupid hopping topic, that I've pissed away something like 13% of my shares while I was fucking around tuning a miner. Does that sound like a hopper? Instead of catering to crybabies, I'd rather eleuthria spend his time fixing the API and keeping the pool running. |
|
|
|
It's not cheating. It's stealing. If you pool hop you are stealing from the people who use the pool in the intended way.
Use this as a learning experience. A sense of entitlement does not actually entitle you to anything. Life in the real world isn't much different than this, so learn quickly. Now, if you actually understood what stealing was, you would know that hoppers are being paid their fair share and those who don't hop are being paid their fair share. You may not think it's fair, but the specifications for the compensation method state that it is. Nobody is depriving anyone of what is rightfully theirs. Maybe it's just that you aren't very good at this game and are annoyed that you didn't find out how to play better than some other kids on the block first, so you're hiding behind a slightly twisted morality instead of just doing a little math. The intended way to use this pool goes like this: voluntarily contribute your processing power in units called shares and receive proportional payment for them. Hopping is built into it because the compensation method is broken, according to you. You just don't like the pool rules, are too territorial, and have an overactive pack mentality. Puberty is a bitch. Now, this game is being run more like a casino. The rules are set in place, but the casino makes a few extra rules on top of those, targeting a small class of winners (i.e., persecution), to "level the playing field" for the dummies and those just out to "have some fun". Since some people can count cards, they gets their fingers broken. This is like kind of like delayed stats. Everyone pays because the rules are bad and those who are better at the game don't make the casino a nice place for retards. It's a huge step back from a meritocratic system. It will be lovely and enjoyable for everyone when it turns into a *real* slush pool flooded with redneck AOL/geocities types who can't figure out which port on their computer the bitcoins are going to come out of. |
|
|
|
Really? What if you get an InterruptedException before you return from getWorkQueue.take()?
Then I should be checking for the exception, not if it is != null. Yes, a better alternative would be to move your getWorkParser variable declaration at 819 and everything below and outside of the catch (830-853) into the try block. Since I'm a stickler about these things, I would also make getWorkParser final and toss the unnecessary null assignments to get rid of another possible null dereference compiler warning. If you were aggressively nulling the variable because it was in a loop because you were worried about holding a reference in the loop, that GC weirdness workaround hasn't been necessary for a very long time. Besides, you will be reducing scope now, which is cleaner than null assignment, and the GC is non-deterministic, anyway. |
|
|
|
its not my idea. but i am currently thinking about writing a patch for bitcoin.
The hub mode patch is probably sufficient. |
|
|
|
Eh, too much trouble. I see you already fixed the exec java bit for Linux. For the others, replace your !"".equals(String) calls (8 instances) with a call to a method like this: protected boolean hasLength(String str) {
return str != null && str.length() > 0;
}
Your splitting on commas for pool support breaks values with commas in them (e.g., passwords). Around 831, there should be a null check on getWorkParser. Java coders prefer checking against "" instead of checking length for some reason. Almost all the places I check also check for null as well. Maybe retarded Java coders. !"".equals(null) evaluates as true (!false). You intend for it to return false, as in this case: if(!"".equals(url.getUserInfo())) {
String[] userPassSplit = url.getUserInfo().split(":");
If url.getUserInfo() returns null, you will proceed into the conditional block and dereference a null. if(hasLength(url.getUserInfo())) {
String[] userPassSplit = url.getUserInfo().split(":");
hasLength will return false, and skip the block. Hurrah. And why around 831? At no point can that be null.
Really? What if you get an InterruptedException before you return from getWorkQueue.take()? Lesson complete. |
|
|
|
Would you prefer I turn back time and hide the fact that its a 1 hour delay? If you were mining here continuously you would never know the delay existed in the first place.
Really? Like when a miner dies and the number keeps going up? Or when all miners are restarted after an outage and the number is stagnant? |
|
|
|
It sounds like the pool hoppers are butt hurt.
There are other pools out there if you don't like it. I applaud the change personally, and my measly 3.5 GHash/sec will be back after this weekend (which I said I would put towards simplecoin.us).
EEF YEW DUN LAHK DIS CUNTRY, WILLL GIT AHTT! |
|
|
|
Lets see, two days ago:
"I'd join BTC Guild but pool hopping will hurt my return"
-Debate ensues, eventually someone sends me a complete breakdown of exactly what pool hopping can do for their return and shows how it HURTS LEGIT MEMBERS-
Now: 1 hour delay added
"OMG WTF YOU'RE HIDING OUR STATS FOR AN HOUR I'M LEAVING"
Damned if you do, damned if you don't.
For those leaving, think about this one simple fact: Legit users returns ARE reduced by pool hoppers. MY RETURNS are increased because of the speed fluctuations pool hoppers bring at the start of each round. I just reduced my income to help legit users.
Pool hopping is not a *problem*. It is a condition of the system. If you absolutely insist on your current compensation method, that is how it works. You are dealing with other people's processing power, and it is up to them to use as they see fit. I don't see a problem with your compensation method, and I don't see a problem with pool hopping. I can see how people with small dicks want their 0.0001 BTC on the BTC back, but it's really inconsequential. Transparency is more important, but the squeaky wheel gets the grease, right? I don't pool hop, but I do use the API to tell me whether or not it is even worth it for my few miners dedicated to mining *solely* with BTC Guild to bother. I don't like monitoring this shit or threads with kiddies bitching about pool hoppers "stealing" their money. I write programs for that. You probably took a good thing and made it worse, so maybe I'll write new programs or just purely solo mine and make the same amount. I don't even donate, but I planned to at some point. If the pool is even up, if the API even works, and if BTC Guild even is what it used to be, maybe I will soon reach that point. The sky is falling! Not really, but WTF? "Legit" users can pool hop. In fact, it's in everyone's interest that everyone pool hop. If the "vulnerability" is essentially written into the system, you would be a moron, or too lazy, to *not* pool hop. If everyone did it, there would be no benefit. Those who don't will complain all of the way to the proverbial grave. Here's some kleenex, pussies. Now, maybe eleuthria can make more changes and fuck up the pool a little more and everyone will be happy. Well, Tycho also gives advice that (in theory) will reduce his income. That's part of the "civic" aspect of being the dude at the top of the #1 or #2 pool. You know better than anyone of us how many thousands of hours you have worked to get this pool up, right? Aren't you making out with some nice coin, Eleuthria?
Thousands? He was working 40 hours/week for a year on this? |
|
|
|
I am not convinced that stat delay will solve the issue as there is already a published method to deal with deepbit's delay.
There's probably also one for BTC Guild's. |
|
|
|
The API is returning invalid JSON if you have no current shares again. If you're using TOR, expect shitty rejected share rates. Just an FYI. The IP changing of TOR will mark your account as a potential botnet and give you last priority on LP updates/getwork processing.
Weak. |
|
|
|
Eh, too much trouble. I see you already fixed the exec java bit for Linux. For the others, replace your !"".equals(String) calls (8 instances) with a call to a method like this: protected boolean hasLength(String str) {
return str != null && str.length() > 0;
}
Your splitting on commas for pool support breaks values with commas in them (e.g., passwords). Around 831, there should be a null check on getWorkParser. |
|
|
|
|
