several months isn't 'a little bit of bad luck'.
It wasn't; the evidence points to Eligius having been the target of a block withholding attack. Luke-Jr posted this to bitcoin-dev about a week after Eligius started falling behind very badly: http://article.gmane.org/gmane.comp.bitcoin.devel/1112No, there is actually no evidence of that (as far as I know). My post was related to brainstorming the withholding attack which might (or might not) have come from a discussion on the possibility of it that wouldn't have occurred if we had a nice big buffer, but it was certainly not directly correlated with any kind of actual in-practice problem to my knowledge. |
|
|
|
bfgminer 2.6.1
windows 7 x64
driver 12.6
SDK 2.7
D:\bfgminer>bfgminer.exe -o http://X.X.X:XXXX -u XX -p XX --scrypt -g 1 -I 13 --shaders 1792 --thread-concurrency 1792 --lookup-gap 2
[2012-08-02 19:33:27] bfgminer.exe: --scrypt: unrecognized option Doh, I added SCRYPT-README to the release, but forgot to --enable-scrypt I've added it to my list of issues to fix for 0.6.2, which probably won't be too long. |
|
|
|
Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started. It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely. CPPSBAM works against miners who leave the pool, plain and simple. If you don't want to mine the pool and support it, then you don't get paid. Easy as that. If you feel like supporting the pool later, then by all means "unlock" your EC.
-wk
Certainly you aren't saying that hash rate determines luck. Otherwise, the little miners don't stand a chance. It does play a part in how quickly the variance ("luck") swings from one extreme to the other. |
|
|
|
several months isn't 'a little bit of bad luck'. perhaps something is broken and that should be addressed before changing the payout system? Several months isn't a little bit, but it is within the normal expectations. How many months of a positive buffer did we have? That's no more likely than extra credit. That being said, there is also the "the bigger the block, the more likely to be orphaned" problem that lost us 6 blocks before being caught. That has been addressed for the short term (making smaller blocks) and I am working on addressing it for the long term (patching the reference implementation to minimize block propagation time regardless of transaction count). |
|
|
|
cgminer dont work with BFL singles count > 13
crash
windows 7 64
BFGMiner should. If not, report a bug. |
|
|
|
Keeping in mind the author is trying to make specific reward systems look better than others. |
|
|
|
I've been using eligius.st but they don't update their statistics very often and don't tell you why they rejected a block (i.e. stale vs. bad hash, etc). Um, what? Direct access to the PostgreSQL database is available, and every submission returns the rejection reason in the headers... |
|
|
|
Is there a way to put this command line into a config file?
-S \\.\COM20 -S \\.\COM22
Because every combination that I tried either failed or only detected one of the two ports (like "scan-serial":"\\\\.\\COM20,\\\\.\\COM22", "scan-serial" on two lines with each port etc...)
"scan-serial":["\\.\COM20", "\\.\COM22"] |
|
|
|
I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects (cgminer had almost none 0.07%), but at least it works  . No, CGMiner has them - it just hides them from you, along with other shares that would have been accepted... Angry neighborhood bastard mod here. Go FUD on some other forum, your kind isn't welcome here. It's not FUD since it's true. |
|
|
|
Why give it a specific timeline at all? Why not just wait until the exploit is verifiably fixed? If concerns arise about the exploit not being fixed in a timely manner, THEN threaten to release the exploit unless it is fixed by a particular date/time.
CVE-2012-2459 was announced nearly 3 months ago, and has reached 75% deployment. The disclosure is scheduled to happen at 77%, which I expect to be reached in a month or two. Considering that upgrades happen on a per-node basis often run by an individual human each, this "within 6 months" timeframe seems quite reasonable to me. |
|
|
|
so if i am not mistaken the main difference between LTC and BTC was the fact that LTC was targeted at CPU mining only.
now that you can mine it on GPU, arent both currencies basically the same? making one redundant?
Litecoin was always redundant, and a scam. There is reason to believe the original designer of the scrypt algorithm had been GPU mining it from the first day. Also, it's impossible to make a CPU-only proof-of-work. Ironically, now that GPU mining is public, they're claiming it's ASIC-resistant which is even more absurd (nothing can be ASIC resistant). |
|
|
|
I was just about to post how I've been running 2.6.1 with my BFL singles for 2 days straight without problem, and then I caught these errors. I restarted cgminer and it's working again for now. This is almost certainly caused by Kano's reduction of the timeout from 30 seconds to 0.1 second... I skimmed over this one and assumed it was 1 second (which is at least reasonable). Bet this is what was causing the other problems people reported too... thanks for the tip  I'll fix it for the next BFGMiner. |
|
|
|
With the last firmware for the original board, is the 4th slot working? As I'm looking at getting a 4th child board. It should be, but I only have 3 working FPGA boards, so I haven't been able to test all 4 at once (slots 1,2, and 4 together do work). Cablepair was just testing the new boards before shipping them out, so he probably can expand on that. Also what is the latest with the current firmware, And miners? We're working on a new protocol to work more efficiently (no polling) and can adapt to other bitstreams (like Tricone). |
|
|
|
Here are the results I've got for both miners running around 45k shares across 3 longpolls both: Unfortunately, I've found even using the same device for even more shares does not produce comparable U results, even with the same exact software. Feel free to confirm this yourself by doing the same test over. Well, I didn't comment the results, since I don't really know that much about the output data it gives. All I can say, is that U fluctuated in both miners from 716 to 722, but in general cgminer shows higher U, and bfgminer shows higher average Ghs speed. Human pattern analysis is always suspect  Also, you're comparing cg2.6.1 with bfg2.5.1. At the very least, it'd be better to compare equivalent versions. But first, it'd be wise to try to find some way to reproduce consistent results with the same software - until then, there's really no good way to compare.  |
|
|
|
Here are the results I've got for both miners running around 45k shares across 3 longpolls both: Unfortunately, I've found even using the same device for even more shares does not produce comparable U results, even with the same exact software. Feel free to confirm this yourself by doing the same test over. |
|
|
|
Since the newest version 1 out of 4 singles dies after a few minutes. Restarting bfg miner gives me another few minutes.
Is it always the same Single? Can you (or anyone else experiencing this) meet me on IRC (later today - about to go to bed) to troubleshoot? chat.freenode.net #eligius |
|
|
|
I've got mini rigs hanging after some time with cgminer 2.6.1 so I switched back to bfgminer 2.5.1. It does produce almost 1% more rejects (cgminer had almost none 0.07%), but at least it works . No, CGMiner has them - it just hides them from you, along with other shares that would have been accepted... |
|
|
|
FWIW, any BFGMiner issues (including bugs in the FPGA drivers, that CGMiner copied from BFGMiner) should be reported in detail here. I'm also available in #Eligius for real-time troubleshooting. Hmm - well the actual correct term is a pull request you sent to cgminer ... but anyway ... That's fine, I can't see what luke-jr says anyway since ignoring him unless someone else quotes him and only allow him to speak to me in c code. Since he still seems to have the same attitude and spams my thread, I can just ignore his code as well. Rather than showing humility it seems he is getting worse, so perhaps it's time to refuse to take any more code. And so Con's fork deviates yet even further... guess that means he'll be rejecting the bitforce bugfix. |
|
|
|
|
Show Posts
