Luke, I switched over to CGMiner, but one thing I think is clear, I don't think the frequency option (--set rockminer:clock=290) is working properly with BFGminer (4.2.x). When I configure frequency=290 with CGMiner, I get over 35Gh. With BFG, the best I ever got was in the 32's regardless of the frequency number.
Seems to work fine for me. Try --set rockminer:clock=200 for example, it's clearly slower. Be sure you're comparing the pool-side hashrate, since cgminer lies about it... |
|
|
|
|
FWIW, while I don't have much insider knowledge in BFL day-to-day operations, I do know that as of right now, Nimbus doesn't have software working for any 28nm BFL hardware.
Only just recently, did we finish getting BFGMiner to work properly with the Monarch (despite the announcement for its support in 4.0, there were some bugs that came up as BFL tweaked the firmware to get to the full hashrate).
Nimbus currently relies on a proprietary fork of cgminer, so they can't even deploy that right now.
And while it's possible they could use software I'm not aware of, I was recently asked (with pay) to help adjust Nimbus's operation so it could handle the Monarch - which wouldn't make sense if they already had something working.
So, at least that part of this guy's story sounds like it's completely bogus (which makes me question the whole thing, even if I can't personally refute it).
Trolls who are going to FUD against my credibility, don't bother: I'm not putting this up here for you, but for the honest people who might otherwise not know better.
|
|
|
|
|
Quick FYI: On Linux, I strongly advise NOT trying to use -S bitforce:all
I just noticed this attempts to open and talk to every single PCI device.
That could be very bad...
Will fix in next release.
|
|
|
|
Is the pool having issues or is it just on my end? I have some miners saying the pool is alive and some miners saying it's dead.
Had a couple disconnect for a bit, but not all and back to normal now. Me too. As of about four hours ago I see that two of my miners seem to have rebooted themselves. I say reboot because they both have Uptime of a little over three hours. WhizKid or Luke? any thoughts?? If a pool could reboot your miners, there is something wrong with the miner... |
|
|
|
But yea, we're digressing; still curious if user javascript could be made an option? Thanks! I think all major browsers support client-side user javascript these days. Any reason that wouldn't work for you? |
|
|
|
|
This should be fixed now (the hard drive was full).
Can you guys confirm it is now working for you?
|
|
|
|
Rockxie - has anyone on the team looked at bluetooth integration for future designs? Would save the pain of crossing 10's of wires (idk, maybe 100's for some of the more enthusiastic out there) and could be a value-add to the design.
Personally, I think it'd be pretty cool if someone did a 6lowpan miner  |
|
|
|
Please test the "zeusminer" branch in my GitHub repo. This is nwoolls' latest code with some minor cleanups (and a fix for big endian). Windows builds here |
|
|
|
|
I keep forgetting which scam accusations are confirmed or only suspected and/or potentially technical trouble.
Thoughts on having a page that lists suspected and confirmed scams, that we can just redirect these pages to when confirming?
|
|
|
|
This guide has helped me the most at getting my solo pool up and running. My only problem is not being about to get the pool to use var diff. All of my miners return diff 1 shares.
In my config.py I've got
ShareTarget = 0x000000000ff.........
DynamicTargetGoal = 6
DynamicTargetWindow = 120
Am I missing another setting somewhere?
I don't think you enabled it? |
|
|
|
No, the proposal here doesn't really solve 51% issues at all.
Explain? If the pool is not in charge of the block's contents - then how does it not fix the issues associated with having 51%? All you've done is move the issue to another, new kind of pool. Which could BTW be under the same control as the person running the current pool. It also means the current-pool selects which new-pool to use, so net effect: ZERO. |
|
|
|
It seems I received a partial payment of my total due balance. Didn't lose the unpaid portion, it stayed in the total due. Never noticed this before...anyone?
Stats link? |
|
|
|
This is just a roundabout and centralised way to do getblocktemplate...
Seems pretty pointless.
Completely the opposite. GetBlockTemplate would require the pool to verify every transaction is valid, and that the block itself is entirely valid, just to be able to credit a share - as I understand it, it is a computational nightmare. No, pools don't have to check every transaction at all, just the coinbase. Sure, someone could make an invalid block this way, but they could also do block withholding for the same effect. The miners and pool software would not have to be fundamentally altered to such a large degree, but the resultant change of control would solve every problem of 51% ownership. No, the proposal here doesn't really solve 51% issues at all. |
|
|
|
|
This is just a roundabout and centralised way to do getblocktemplate...
Seems pretty pointless.
|
|
|
|
Everything contributed is Creative Commons Attribution 3.0 licensed.
Text, yes, but not images (or at least, that's how it should be). The strong majority of images are fully copyrighted and haven't been released under a free license; they should either be tagged as being used under fair use, or deleted if the wiki's policy is to only accept free images (which wouldn't make sense, considering that the nature of most articles requires copyrighted images, such as website screenshots, logos, etc.). Pretty much every wiki runs this way; their text is freely licensed, but images are independently licensed as needed. I don't see any exception for images. Pretty sure website screenshots aren't copyrightable. Similarly, logos may be trademarked, but I don't think copyrighted. |
|
|
|
|
Everything contributed is Creative Commons Attribution 3.0 licensed.
|
|
|
|
Thanks for the quick reply!! The lowest diff I can set on the page is 4 which means I'll have to ssh and try to set it manually.
I'll let you know how it goes. Thanks again! If you can compile, there's a hack on https://github.com/luke-jr/bfgminer/pull/456 you could merge to make it diff 16. |
|
|
|
Luke,
I'm using BFGminer to proxy a Dragon 1T miner & it seems to be working well except for the reported speed. The miner as well as the pool are reporting roughly 1TH while BFGminer is reporting 11.xx Gh. Kinda like the decimal is
two places to far to the left ...
I've heard Dragon miners are broken and require you to set the share difficulty on the device itself. For BFGMiner's stratum proxy, the correct value is pdiff 1. |
|
|
|
To that effect we are in the process of arranging contact to the leading mining pools and Bitcoin Foundation to propose a ‘round table’ meeting of the key players with the aim of discussing and negotiating collectively ways to address the decentralisation of mining as an industry. Our aim is to do this quickly with a possible date coinciding with the CoinSummit Conference in London. This has been ongoing since 2012 on mailing lists and IRC. Please join and participate. GHash.io is the only major pool that has not been involved in inter-pool relationships. |
|
|
|
I am not wrong no solo pool will be hurt by the attacker. Um, so you get the worst of both worlds? Just solo mine for real. |
|
|
|
|
Show Posts
