Which is fine so long as Bitcoin's central bank's client
Huh? You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin. Only if you let/make us. So, given that Bitcoin's mantra is decentralisation one assumes you would advise people to use a client other than the official one, otherwise everything gets all centrally and we known how much Bitcoin cultists hate that. There is no official client. I'll advise people to use the best tool for the job they want to accomplish - often that's Armory. Unfortunately, there aren't many good tools out there yet. |
|
|
|
Which is fine so long as Bitcoin's central bank's client
Huh? You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin. Only if you let/make us. |
|
|
|
It's not possible for pools to do this without miner cooperation - for example, by them using the stratum protocol. As long as miners are taking advantage of the GBT protocol, this attack is not possible since the miner finding the block will announce it to the network themselves. Which is fine so long as Bitcoin's central bank's client remains the defacto standard. As other mining strategies are discovered there will be ore and more clients available running forked mining code. Huh? You don't need any forked mining code for this... |
|
|
|
It's not possible for pools to do this without miner cooperation - for example, by them using the stratum protocol. As long as miners are taking advantage of the GBT protocol, this attack is not possible since the miner finding the block will announce it to the network themselves. For BFGMiner, you need to configure it to failover to solo mining: bfgminer ...put your real GBT-based pools first... -o http://localhost:8332#allblocks -u username -p password |
|
|
|
Luke, Are you checking your PM's?
I already replied to yours earlier... O.o |
|
|
|
Hi WK,
can you implement a supposed PPS reward so we can compare our reward to the PPS reward system?
It also helps to show how your system fair up to PPS in long term.
That's what the % is (or Maximum Reward on the graph) |
|
|
|
For now we are most believe in ORICO A3H10 hub. Price per port is right and quality is very good. But they will always be OFF after a power failure. I'd recommend the ORICO P10-U3 instead. I might have to take this recommendation back - mine just started causing Linux kernel panics every time I plug it in... |
|
|
|
Received last payment at 12:19 PM today but since then Eligius found 24 blocks and my User stats Page indicates each block brings me only 0.0225 BTC. I own about 0.00245% of the pool so each block should get me something closer to 0.061BTC. What 's going on??? Am I the only miner with that issue??? 0.02245 * 25 BTC = 0.56125 BTC Estimated Change: +0.05160145 BTC |
|
|
|
Why is not possible to Install it on CENTOS and REDHAT  Pretty sure a number of people use it on RedHat/CentOS. It's my understanding they'll soon have a package in the official repositories. |
|
|
|
What am I doing wrong (or is it environmental!) ? OS issue, missing IPv6 support. |
|
|
|
|
Could just change your minimum payout to something lower too..
|
|
|
|
Luke, can you comment on the following, regarding BlueFuries: They draw 0.5A from what the EE has told me. The command would be along the lines of. bfgminer -S bigpic:all -o pool -u user -p pass
Also if you are using bfgminer from Luke's build you won't be able to probe for both block eruptor and blue fury as both probes will break each other. If that makes sense? Hmm. I plan to run two separate instances of bfgminer, where one instance would only control/probe for Erupters (-S erupter:all), and the other - only BFs (-S bigpic:all). Hope this works. If not, I'd need to plan for all BlueFuries running from a separate machine. I don't think cgminer has the same issue. One option would be use a old version of bfgminer sub 3.3.0 so it is only compatiable with the block eruptors and then use our version of bfgminer. Theoretically that should work. Luke might know a better idea or he might have some kind of fix in the works I am not sure. Just don't use -S <anything>:allThis tells BFGMiner to probe every port for the <anything> device. Erupters can't handle BigPic probes, and BigPic can't handle Icarus probes. |
|
|
|
especially if you are running multiple pools that have different coin... This is not supported, nor planned to be supported. It wrecks havoc on the internals of the mining framework, so it wouldn't surprise me if it fried your CPU or caused your GPU to explode or anything. As the README says: Do not use on multiple block chains at the same time! |
|
|
|
first post: "For miners using ModMiner, X6500, or ZTEX devices, you will need to download bitstreams for BFGMiner 3+ to work with your device. Download links and instructions are included in the README.ASIC file." shouldn't README.ASIC read README.FPGA  Fixed, thanks. |
|
|
|
|
I plan to rewrite all the work distribution code at some point to complete GBT support.
|
|
|
|
|
More likely I'd just make rotate based on the new quota system.
But there's so many higher-priority things right now, I don't think I'll be able to get to it for a while.
|
|
|
|
Will this help, http://projectklondike.org/I use your miner for all my USB ASIC Miners and it does a fine job, I sure would like to use it for my K16's  I sent LiquidSynDesigns a message, but it's probably more effective if existing or potential customers also request support. |
|
|
|
it is seemingly detecting the chili however I'm unable to see the individual chips under the [M]anage Devices section. This is due to Chili being based on a very old protocol. The error message that I keep receiving from the BFL 1 (chili) device is 'Failed to send queue, and queue empty; retrying after 1 second" This is due to bugs in the Chili firmware. I think they plan to release a fix at some point. BFGMiner 3.5 has a workaround for it, but it needs to use more USB bandwidth than normal. Do you have a link handy? I'm only seeing version 3.4 Sorry, typo. I meant 3.4. |
|
|
|
Any update for the settings in BFGminer for Klondike K16 mining unit?
Klondikes are, AFAIK, completely unsupported. I'd be glad to add support, however I have nothing to work with. Please ask your vendor if they can provide specifications and/or a sample unit. |
|
|
|
it is seemingly detecting the chili however I'm unable to see the individual chips under the [M]anage Devices section. This is due to Chili being based on a very old protocol. The error message that I keep receiving from the BFL 1 (chili) device is 'Failed to send queue, and queue empty; retrying after 1 second" This is due to bugs in the Chili firmware. I think they plan to release a fix at some point. BFGMiner 3.4 has a workaround for it, but it needs to use more USB bandwidth than normal. |
|
|
|
|
Show Posts
