|
I'm getting a 500 error accessing your API
|
|
|
|
|
phoenix miner 1.50, and the latest version of bitHopper
|
|
|
|
|
I'm concerned by the number of stales I am getting on bitHopper. It is running LP, right? I'm getting around 2-3% stales on most sites, including btcguild (backup), which without bitHopper my stales were < 1%
|
|
|
|
 Glad I jumped in before the rally. I'll be getting my burrito all the way tonight! Wow, one hell of a rally, even the chart couldn't make up its mind to show the price in red or green |
|
|
|
There you go, see that surge at 3:30? |
|
|
|
|
As usual, Google knows all:
News for Goldman Sachs bitcoin
Goldmen Sachs Shares Surge On Announcement of Bitcoin Trading Unit
Unconfirmed Sources (satire) - 4 hours ago
|
|
|
|
eleuthria,
I'm sticking with the theory that this is just an unusual run of bad luck, and will hopefully be balanced by a nice run of good luck at some point. But I'm wondering, if the bad luck continues, at what point do you look into the possibility that there is some kind of subtle issue with the servers? I wasn't paying very close attention, but I think I actually had one of the highest 24 hour payouts shortly after you upgraded/moved the uscentral server, which is what I've been connected to. So that is maybe a little evidence against a server issue. Still, the longer this run of bad luck continues, the more improbable it becomes, and at some point I think alternative explanations have to be explored.
The servers are running as usual. Its pushpool, bitcoind, and MySQL is sync'ing up without issue, I've had the most relaxing 2 weeks in a long time actually, other than our luck taking a dive which means all the conspiracy theorists come out of the woodwork to "question" things. Like I said in my last post, everybody "questions" the bad, and ignores the good. Anybody making the claim that our -14% this difficulty is unusual and not raising the same questions about DeepBit's positive 13.6% during this difficulty is a hypocrite. If you want to believe that pool speed will eliminate the chance of variance "that high", then it's more than twice as unlikely for DeepBit to be pushing that luck as it is for us. For the third time, I did not bring it up due to the -14% luck this difficulty, in fact I weighted down the luck this difficulty because it isn't over. I brought it up due to the longer term always being negative. Given the high hash rate of the pool, having so much bad luck is unusual, and can be indicative of a problem. Do miners not have the right to keep a skeptical eye on those we entrust? What if we had another 2 months of negative luck, would it be ok to question then? It's not like I can go look through your code to make sure everything is on the up and up, so I can only look at these statistics. Question: did you run pushpool without looking first, or did you simply trust it? Being skeptical is good business sense. A lot of people out there are more than willing to screw you over |
|
|
|
yersss, and it just so happened to coincide with all the hoppers using them again. They'd been fine for the last week or two previously. Infrastructure again. I've turned them off.
btw getting 120% on slush.
Im getting ~250% on deepbit  Just took shot in the dark over the last 2 days when i noticed they are running hot as hell and sliced part of my farm dedicated to deepbit lol I'm getting ~275% on mtred, and I once caught a fish |================| this big |
|
|
|
I once played a thousand rounds of Russian roulette, too, and not once have I ever had a serious problem.
I would have to guess that you either are extremely fortunate, or mistaken. I've actually worked with computer hardware, and I've lost count of the number of components which were damaged by an unexpected loss of power. Usually crappy low end power supplies. And that's not even getting into filesystem corruption. If you've never seen a corrupted hard drive from a Windows box, you've likely either never used a computer or you're extremely anal about taking care of it.
Perhaps the damage was cause by a spike that caused the unexpected loss of power. I've had that happen plenty of times. In fact, right now I have a Boxee which can only work on WiFi because a damn lightning strike blew out its wired adapter. And no, I have never had a hard drive become corrupted by an unexpected shutdown, and really I don't even see how that could happen unless you are rewriting the geometry of the drive when it happens. Under any file system, if a file failed writing before a commit, you'd simply lose the file. If the file were mission critical to the operating system, then you might have issues booting, but that would only happen during a system update. Even then, it would be unlikely. My statement was more of an introspection than anything. That is a standard axiom of techs, and upon reflection of my experiences I wonder how valid it actually is. Also, granted you don't know me so of course you get a pass, the insinuation that I never used a computer or I'm anal about taking care of it is laughable. I've been programming since I was 9, I ran a BBS in my teens-(5 geek points if you even know what that means), and I run a network at home that most small businesses would envy. I know my shit  |
|
|
|
2) Can we add something to skip/not show disabled servers in the new stats like gnaget did a couple pages back or add a role like removefromlist?
Actually, if you use the role of removefromlist, and change my code from comparing to =="disable" to =="removefromlist" you'd probably get the exact behavior you are looking for |
|
|
|
Nice ideas, code a patch/fork and do a pull request!
That is so much harder than just letting c00w worry about it |
|
|
|
/live/cow (which I would guess is the persistent overlay) is journaled. The rest is not.
Is that good? Im guessing the persistence file is the only thing that changes while the system is running. I do remember having to add a persistence file to the usb stick image. So should I be okay resetting this system forcefully? There's always some risk to a hard reset and you're better off to do a normal shutdown and reboot whenever possible. You know, I have heard that my entire life. I have been working on computers in a fairly advanced capacity for over 2 decades, and I must have done tens of thousands of hard resets, either intentional or forced, and not once have I ever had a serious problem. |
|
|
|
|
I'm now running:
poolmunity.com
polmine.pl
bitclockers.com
bitcoinmonkey.com
mtred
bitcoins.lc
rfcpool.com
triplemining.com
nofeemining.com
ozco.in
Anything obviously stupid stands out?
|
|
|
|
oh, and c00w if you find a moment, perhaps you can give the option on the stats page to not show disabled pools? Not a big deal either way, I put a quick 2 lines of code in there to not show them
What's your code? I'd like that also. In index.html I did this: for(v in data["servers"]) {
var srv = data["servers"][v]
if (srv["role"]=="disable")
continue;
h += "<tr>";
In the javascript I moved the h+="<tr>"; line down, and added the if satement, so when it comes across a disabled server, it doesn't write it out, but simply continues on |
|
|
|
Not that it matters, I think. I don't know about y'all, but I have all of 4 pools that are hopable, and of those, only mtred cycles with any regularity
Polmine bitclockers ozcoin triple nofee bitcoins.lc mtred rfc A lot more than 4 pools to use. ozcoin, nofee, triple, mtred and bitclockers are the backbone of making a ton of BTC. bclc is good on short rounds. rfc and polmine solve like one block a century, but if they get lucky and get a short block you score massively. What about poolmunity and bitcoinmonkey? |
|
|
|
|
oh, and c00w if you find a moment, perhaps you can give the option on the stats page to not show disabled pools? Not a big deal either way, I put a quick 2 lines of code in there to not show them
|
|
|
|
bitclockers has been awesome for the last few days. Just gotta find which of these is the best for you:
pool.bitclockers.com
pool1.bitclockers.com
pool2.bitclockers.com
pool3.bitclockers.com
pool4.bitclockers.com
Why is it in the do not mine section? Edit: Nevermind, just saw c00w's response |
|
|
|
I'm not happy I am going to say this, but I am sold on hopping  Ethical issues aside... it is a lot more fun. Getting .7 BTC for 5 minutes of mining kinda kicks ass too Welcome to the Church of Hoppers. I babtise thee in the name of the Stale, the Share and the holy Block. Not that it matters, I think. I don't know about y'all, but I have all of 4 pools that are hopable, and of those, only mtred cycles with any regularity |
|
|
|
I'm not happy I am going to say this, but I am sold on hopping Ethical issues aside... it is a lot more fun. Getting .7 BTC for 5 minutes of mining kinda kicks ass too |
|
|
|
If you think -7.5% and our current difficulty luck is suspicious, I'd recommend you stay quiet if anybody ever asks your opinion on probability and statistics. Everybody is quick to jump to conclusions when luck is negative.
I don't see anybody saying "I think he's adding fake blocks to make us happy" when Deepbit has had 12% positive luck during this difficulty while being MORE THAN TWICE our size, considering according to your post you think that having 2.0-2.4 Th/s should make such a huge luck (positive or negative) should be "extremely unlikely.", which would infer having 5.1 TH/s should make it even more "extremely unlikely."
It isn't our current luck that has me concerned, but our luck going back. I won't go into details because I don't want it to be implemented, but there is one specific way to cheat that would be very easy to pull off. It would be nearly undetectable and the only symptom would be bad luck. The problem is, going back 2 months there has been constant bad luck, not some up some down. I'm questioning, but not accusing you. I don't know you, and I have come to realize that a lot of people in bitcoins are inherently dishonest. Unfortunately, there is really no way for the miners to act as a check on the pool, so we have to make these judgements. |
|
|
|
|
Show Posts
