Stats are shown whenever you report threads for one reason or another, and reports help keep the forum in order.

I have >100 reported posts so far with close to 100% accuracy.

Anyone else?

Since mining altcoins has proven profitable, there is endless discussion about it everywhere in the forum now, especially in the bitcoin/mining subsection. The signal to noise ratio for people interested primarily in bitcoin is dropping rapidly.

Should 1. The topics be moderated/moved to not include any altcoin discussion, 2. More subsections created for altcoin discussion (such as mining), or 3. Pretend altcoins are part of bitcoin?

Why is there an option to create a new self moderated thread (for me in mining software) but there is no way to convert an existing thread to one?

First Second Third FINAL of 4 for sale. Overclocks stable to 1200 for months at a time at stock voltage. This card is one of the first 7970s fully imported from the USA of excellent ASIC quality.

These were the babies used extensively for developing cgminer to work well on 7970s

See:
http://www.ebay.com.au/itm/SAPPHIRE-RADEON-HD-7970-3GB-GDDR5-/321193141293

With the upcoming HUGE hashing hardware starting to hit, now would be a good time to consider supporting higher than 1 difficulty shares for bigger miners which would allow pools to scale without as much increase in bandwidth and server resource requirements as the increase in hashrates. I'd suggest initially making an optional difficulty multiplier switch for workers on the website, which would scale with the miners' hashrate. Enabling it by default would surprise and confuse many miners, and also some mining software may not support it so they'll just get high rejects unexpectedly. As a rough guess, I'd recommend increasing difficulty by 1 for every 1GH of hashing power. This will not dramatically change getwork rates, but it would change share submission rate and processing of them which is bandwidth and CPU intensive. There would be issues with fluctuating hashrates and difficulty targets when precisely on the 1GH boundaries, and this could be worked around by the user setting their own target or by using some hysteresis for the change up and down of targets to avoid frequently flicking between difficulties.

Conspiracy theory time. Is BFL testing all its minirigs or do we have a new botnet?

http://blockchain.info/blocks/24.211.152.165

There's a flurry of blocks from that IP today.

So it appears pretty clear that most pools are suffering from a significant rise in orphan rates and many pool owners believe the issue appears to be related to slow block solve propagation due to the massive increase in transaction volume (mostly due to satoshidice).  Now it's clear that while only a small number of us are gamblers and care about satoshidice's success, the fact is most users of sd are obeying the transaction fees as determined by bitcoin (which are rather small now, but still present). So we're hitting some scalability issue with the network sooner than imagined. Some say that bitcoin was never meant to be a system for micro-transactions but that actually appears completely wrong to me if we're to assume widespread acceptance of btc.

I've seen massively delayed longpolls from various pools now and some just accept the shares long after the block has changed before they're sending out the longpoll, while other pools have a deathly pause, not returning a response about shares for up to 25 seconds, then sending out a longpoll and 25 seconds worth of rejected work. Some say that deepbit's transaction limits means they're avoiding this problem, but I'm not informed enough to know if this is true, but it would seem to me this must incur significant transaction delays. Some solution needs to be worked on that benefits all - pools, miners, and bitcoin at large. I don't want to see transactions delayed for up to 6 hours when even transaction fees are paid, but nor do I want my pools to become a massive orphanage.

Please discuss.

I've seen it reported on numerous occasions that on some motherboards when you get to about 5 GPUs, they won't work unless you increase the PCIE latency from 64 to 96 in the bios. As it turns out I recently added a 4th 7970 to my GD70 motherboard and ran into precisely that issue. Xorg would crash every time I tried to start it with all 4 GPUs. So I went into the bios and tried upping the PCIE latency to 96 and then it worked fine.  Anyone know why that is?

[SOLD]

http://www.ebay.com.au/itm/ws/eBayISAPI.dll?ViewItem&item=320848218295 SOLD

Ran perfectly stable at 950 Mhz engine clock for 6 months.

Will accept BTC for payment if purchased through ebay at BTC market price at time of payment.

Increasingly, CPU mining for bitcoins is becoming irrelevant. The only people who still are CPU mining either have access to free electricity by pilfering it off someone else or have some very rare set up involving solar power or something else. Worse yet, it is the number one target for trojans creating illegal botnets or using power on work computers in an unauthorised fashion. The only use I still have for CPU mining is as a test that cgminer works on machines that have no GPUs that can mine.

As maintainer of cgminer, while the CPU mining code is what cgminer started out as, I find it an annoyance to maintain, with random bug reports about difficulty building it, performance being not as good as the best CPU mining algorithms, 64 bit versions not being available for windows, older assemblers failing to compile it, requests for more sse* support, patch submissions to improve CPU mining by .1 MH/s and so on. The fact is it's not much more than annoyance to me and any time I spend working on the CPU mining code is time I could have spent usefully on the GPU mining code. Also, as CPU miners earn almost nothing by mining, their contribution to my BTC balance is never going to be some kind of incentive for me to work on it. The only ones earning a lot from it (the illegal botnets) are most definitely not donating.

Furthermore, FPGA mining code is coming to cgminer, and adds yet another type of device that cgminer will support, but a useful one. At this time, the code has been abstracted out to work with any additional devices in the future, but it also makes it an ideal time to remove the CPU mining code, which is in my eyes, irrelevant.

I would like to remove it entirely, but it wouldn't be difficult to keep the existing code there and make it not compile unless consciously configured at build time. I fear that this will end up being even more work than just leaving it as is, since the same number of people will be wanting CPU support.

Clearly my preference is to remove it. Comments would be appreciated too. Saying "it's good to keep" without explaining why I should have to maintain it will not be a convincing argument. Oh and I'd be happy for someone to step up and maintain it and I would pull their changes into the master git tree unless their code proved unsatisfactory.

Thanks.

Most pools have had their fair share of bad luck over their runtime, but I wonder what is the all time worst recorded hashrate / difficulty of any pool recorded so far? ozcoin is having an exceptionally bad run right now with almost 12 million shares on their current block over the current difficulty of 1192498. Of course one block is no marker for how a pool will perform after that...

It would be quite nice if people helped get them out of this rut.

[All files available for DOWNLOAD from here:http://ck.kolivas.org/apps/cgminer]

This is the official thread for support and development of cgminer, the ASIC bitcoin miner written in c, cross platform for windows, linux, OSX and other, with monitoring, fanspeed control and remote interface capabilities. There is NO SUPPORT for CPU, GPU or altcoin mining in this thread, nor older versions with that functionality, nor any support for unofficial forks of this code.

This code is provided entirely free of charge by the programmer in his spare
time so donations would be greatly appreciated.

Help can also be obtained on IRC: irc.freenode.net #cgminer
READ THE README INCLUDED IN THE ARCHIVE BEFORE ASKING QUESTIONS WHICH CAN ALSO BE FOUND HERE:
http://ck.kolivas.org/apps/cgminer/README

Note that I can NOT provide free personalised support via email or personal messages under normal circumstances so they will usually be ignored.
Apologies, but the demand is just far too great and I must prioritise my time.

All files available for DOWNLOAD from here:
http://ck.kolivas.org/apps/cgminer


Debug builds are in http://ck.kolivas.org/apps/cgminer/debug/

.lrz files are compressed with lrzip http://lrzip.kolivas.org for much better compression and supports extreme encryption technology which is ideal for securing wallets.

LATEST RELEASE: 4.11.0 see:
https://bitcointalk.org/index.php?topic=28402.msg44103867#msg44103867

Git tree:
https://github.com/ckolivas/cgminer

Latest git source tarball:
https://github.com/ckolivas/cgminer/tarball/master

Unofficial OSX binaries:
http://spaceman.ca/cgminer/

NOTE: This code is licensed under the GPLv3. This means that the source to any
modifications you make to this code MUST be provided by law if you distribute
modified binaries. See COPYING for details.


Features:
- Very low overhead free c code for Linux and windows with very low non-mining CPU and ram usage
- Stratum and GBT pooled mining protocol support, including ultra low overhead solo mining
- Scaleable networking scheduler designed to scale to any size hashrate without networking delays yet minimise connection overhead
- long poll support - will use longpoll from any pool if primary pool does not support it
- Self detection of new blocks with a mini-database for slow/failing longpoll scenarios, maximum work efficiency and minimum rejects.
- Heavily threaded code hands out work retrieval and work submission to separate threads to not hinder devices working
- Caching of submissions during transient network outages
- Preemptive fetching of work prior to completion of current work
- Local generation of valid work (via stratum, GBT or ntime rollover) whenever possible, as supported on a per-work item basis
- Prevention of stale work submission on new block
- Summarised and discrete device data statistics of requests, accepts, rejects, hw errors and work utility
- Summary displayed when quitting
- Supports multiple pools with multiple intelligent failover mechanisms
- Temporary disabling of misbehaving pools rejecting all shares
- On the fly menu based management of most settings
- Trickling of extra work to backup pools if primary pool is responding but slow
- RPC +/- JSON interface for remote control
- Bitforce support - singles and minirig
- Icarus support
- Modminer support
- Ability to cope with slow routers
- Submit-old support
- X-Reject-Reason support
- Variable difficulty support
- Share difficulty reporting
- Target and block difficulty displays
- Block solve detection
- ASIC Avalon support
- Bitburner support
- Redfury/Bluefury USB stick support
- Bi*fury USB support
- Hexfury USB support
- Onestring miner support
- BlackArrow Bitfury support
- BFL SC asic support
- Drillbit support
- Klondike support
- KnCminer Saturn support
- KnCminer Jupiter support
- KnCminer Neptune support
- Hashfast support
- Nanofury support
- Minion support
- Antminer U1/2+ support
- Bitmine A1 support
- Avalon2/3 support
- Bitmain S1 support
- Cointerra support
- Dragonmint T1 support
- BFx2 support
- Spondoolies SP10 support
- Spondoolies SP30 support
- Rockminer R-Box support
- Hashratio support
- Avalon4/5/6/7 support
- Compac gekko support
- Direct USB communications
- Device hotplug
- Heavily featured RPC API
- Multicast support
- Proxy support
- Coinbase decoding
- Lots of other stuff I can't remember. See options.

Sample output:

Code:

 cgminer version 4.2.1 - Started: [2014-03-29 10:06:52]
--------------------------------------------------------------------------------
 (5s):4.300T (1m):4.324T (5m):4.240T (15m):4.219T (avg):4.242Th/s
 A:9885432  R:64389  HW:1749  WU:59420.7/m
 Connected to au.ozco.in diff 6.45K with stratum as user ckolivas.0
 Block: a1e68974...  Diff:5.01G  Started: [12:48:48]  Best share: 3.41M  
--------------------------------------------------------------------------------
 [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit
 0: ANU 0       :                         | 1.989G / 1.980Gh/s
 1: NF1 0       :                         | 2.417G / 2.404Gh/s
 2: BXM 0       :                         | 3.798G / 3.781Gh/s
 3: BXM 1       :                         | 3.879G / 3.867Gh/s
 4: BXF 0       :  45.9C                  | 4.959G / 4.908Gh/s
 5: CTA 013219f9: 850MHz 75.4C 0.68V      | 1.056T / 803.3Gh/s
 6: CTA 013219fa: 850MHz 116.1C 0.68V     | 643.6G / 805.5Gh/s
 7: HFS Random  : 645MHz  86C  37% 0.79V  | 1.314T / 1.369Th/s
 8: BF1 0d110c15:                         | 2.275G / 2.288Gh/s
 9: HFS IceDrill: 604MHz  86C  23% 0.80V  | 1.214T / 1.250Th/s
 

---
USB menu:

Code:

Hotplug interval:5
8 USB devices, 7 enabled, 0 disabled, 1 zombie
[S]ummary of device information
[E]nable device
[D]isable device
[U]nplug to allow hotplug restart
[R]eset device USB
[L]ist all known devices
[B]lacklist current device from current instance of cgminer
[W]hitelist previously blacklisted device
[H]otplug interval (0 to disable)
Select an option or any other key to return

Pool menu:

Code:

0: Enabled Alive Quota 1 Prio 0: stratum+tcp://au.ozco.in:3333  User:ckolivas.0
1: Enabled Alive Quota 1 Prio 1: stratum+tcp://hash.mineb.tc:3333  User:ckolivas.0
2: Enabled Alive Quota 1 Prio 2: stratum+tcp://stratum.ozco.in:3333  User:ckolivas.0
3: Enabled Dead Quota 1 Prio 3: stratum+tcp://us1.eclipsemc.com:3333  User:ckolivas_0
4: Enabled Alive Quota 1 Prio 4: stratum+tcp://api-stratum.bitcoin.cz:3333  User:ckolivas.0
5: Enabled Alive Quota 1 Prio 5: stratum+tcp://stratum.btcguild.com:3333  User:ckolivas_0

Current pool management strategy: Failover
Pool [A]dd [R]emove [D]isable [E]nable [Q]uota change
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue

Change settings menu:

Code:

[W]rite config file
[C]gminer restart
Select an option or any other key to return

Display menu:

Code:

[N]ormal [C]lear [S]ilent mode (disable all output)
[D]ebug:off
[P]er-device:off
[Q]uiet:off
[V]erbose:off
[R]PC debug:off
[W]orkTime details:off
co[M]pact: off
[T]oggle status switching:enabled
w[I]descreen:disabled
[Z]ero statistics
[L]og interval:5

On exiting:

Code:

Summary of runtime statistics:

Started at [2011-07-19 14:40:09]
Runtime: 2 hrs : 31 mins : 18 secs
Average hashrate: 1680.1 Megahash/s
Queued work requests: 3317
Share submissions: 3489
Accepted shares: 3489
Rejected shares: 0
Reject ratio: 0.0
Hardware errors: 0
Efficiency (accepted / queued): 105%
Utility (accepted shares / min): 23.06/min

Discarded work due to new blocks: 0
Stale submissions discarded due to new blocks: 9
Unable to get work from server occasions: 16
Work items generated locally: 330
Submitting work remotely delay occasions: 33
New blocks detected on network: 10

Pool: http://ozco.in:8332
 Queued work requests: 3253
 Share submissions: 3426
 Accepted shares: 3426
 Rejected shares: 0
 Reject ratio: 0.0
 Efficiency (accepted / queued): 105%
 Discarded work due to new blocks: 0
 Stale submissions discarded due to new blocks: 9
 Unable to get work from server occasions: 15
 Submitting work remotely delay occasions: 33

---

See README, FGPA-README and ASIC-README for more information regarding command line parameters.

Cgminer should automatically find all of your Avalon ASIC, BFL ASIC, BitForce
FPGAs, Icarus bitstream FPGAs, Klondike ASIC, ASICMINER usb block erupters,
KnC ASICs, BaB ASICs, Hashfast ASICs and ModMiner FPGAs.

---

EXECUTIVE SUMMARY ON USAGE:

Single pool:

cgminer -o http://pool:port -u username -p password

Multiple pools:

cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password

Single pool with a standard http proxy:

cgminer -o "http:proxy:port|http://pool:port" -u username -p password

Single pool with a socks5 proxy:

cgminer -o "socks5:proxy:port|http://pool:port" -u username -p password

Single pool with stratum protocol support:

cgminer -o stratum+tcp://pool:port -u username -p password

Solo mining to local bitcoind:

cgminer -o http://localhost:8332 -u username -p password --btc-address 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ

The list of proxy types are:
 http:    standard http 1.1 proxy
 http0:   http 1.0 proxy
 socks4:  socks4 proxy
 socks5:  socks5 proxy
 socks4a: socks4a proxy
 socks5h: socks5 proxy using a hostname

If you compile cgminer with a version of CURL before 7.19.4 then some of the above will
not be available. All are available since CURL version 7.19.4

If you specify the --socks-proxy option to cgminer, it will only be applied to all pools
that don't specify their own proxy setting like above


After saving configuration from the menu, you do not need to give cgminer any
arguments and it will load your configuration.

Any configuration file may also contain a single
   "include" : "filename"
to recursively include another configuration file.
Writing the configuration will save all settings from all files in the output.

---
Also many issues and FAQs are covered in the forum thread
dedicated to this program,
   http://forum.bitcoin.org/index.php?topic=28402.0

The output line shows the following:
 (5s):223.5G (avg):219.6Gh/s | A:330090  R:0  HW:6904  WU:3027.6/m

Each column is as follows:
5s:  A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
A:   The number of Accepted shares
R:   The number of Rejected shares
HW:  The number of HardWare errors
WU:   The Work Utility defined as the number of diff1 equivalent shares / minute

 AVA 0: 23C/ 47C 2280R | 77.10G/83.20Gh/s | A:120029 R:0 HW:2295 WU:1162.5/m

Each column is as follows:
Temperature (if supported)
Fanspeed (if supported)
A 5 second exponentially decaying average hash rate
An all time average hash rate
The number of accepted shares
The number of rejected shares
The number of hardware erorrs
The Work Utility defined as the number of diff1 equivalent shares / minute

The cgminer status line shows:
 TQ: 1  ST: 1  SS: 0  DW: 0  NB: 1  LW: 8  GF: 1  RF: 1

TQ is Total Queued work items.
ST is STaged work items (ready to use).
SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
DW is Discarded Work items (work from block no longer valid to work on)
NB is New Blocks detected on the network
LW is Locally generated Work items
GF is Getwork Fail Occasions (server slow to provide work)
RF is Remote Fail occasions (server slow to accept work)

---
MULTIPOOL

FAILOVER STRATEGIES WITH MULTIPOOL:
A number of different strategies for dealing with multipool setups are
available. Each has their advantages and disadvantages so multiple strategies
are available by user choice, as per the following list:

FAILOVER:
The default strategy is failover. This means that if you input a number of
pools, it will try to use them as a priority list, moving away from the 1st
to the 2nd, 2nd to 3rd and so on. If any of the earlier pools recover, it will
move back to the higher priority ones.

ROUND ROBIN:
This strategy only moves from one pool to the next when the current one falls
idle and makes no attempt to move otherwise.

ROTATE:
This strategy moves at user-defined intervals from one active pool to the next,
skipping pools that are idle.

LOAD BALANCE:
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.

BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.

---
SOLO MINING

Solo mining can be done efficiently as a single pool entry or a backup to
any other pooled mining and it is recommended everyone have solo mining set up
as their final backup in case all their other pools are DDoSed/down for the
security of the network. To enable solo mining, one must be running a local
bitcoind/bitcoin-qt or have one they have rpc access to. To do this, edit your
bitcoind configuration file (bitcoin.conf) with the following extra lines,
using your choice of username and password:

rpcuser=username
rpcpassword=password

Restart bitcoind, then start cgminer, pointing to the bitcoind and choose a
btc address with the following options, altering to suit their setup:

cgminer -o http://localhost:8332 -u username -p password --btc-address 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ


---
LOGGING

cgminer will log to stderr if it detects stderr is being redirected to a file.
To enable logging simply add 2>logfile.txt to your command line and logfile.txt
will contain the logged output at the log level you specify (normal, verbose,
debug etc.)

In other words if you would normally use:
./cgminer -o xxx -u yyy -p zzz
if you use
./cgminer -o xxx -u yyy -p zzz 2>logfile.txt
it will log to a file called logfile.txt and otherwise work the same.

There is also the -m option on linux which will spawn a command of your choice
and pipe the output directly to that command.


If you start cgminer with the --sharelog option, you can get detailed
information for each share found. The argument to the option may be "-" for
standard output (not advisable with the ncurses UI), any valid positive number
for that file descriptor, or a filename.

To log share data to a file named "share.log", you can use either:
./cgminer --sharelog 50 -o xxx -u yyy -p zzz 50>share.log
./cgminer --sharelog share.log -o xxx -u yyy -p zzz

For every share found, data will be logged in a CSV (Comma Separated Value)
format:
    timestamp,disposition,target,pool,dev,thr,sharehash,sharedata
For example (this is wrapped, but it's all on one line for real):
    1335313090,reject,
    ffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000000,
    http://localhost:8337,GPU0,0,
    6f983c918f3299b58febf95ec4d0c7094ed634bc13754553ec34fc3800000000,
    00000001a0980aff4ce4a96d53f4b89a2d5f0e765c978640fe24372a000001c5
    000000004a4366808f81d44f26df3d69d7dc4b3473385930462d9ab707b50498
    f681634a4f1f63d01a0cd43fb338000000000080000000000000000000000000
    0000000000000000000000000000000000000000000000000000000080020000

---

RPC API

For RPC API details see the API-README file

---

FAQ

Q: Can I mine on servers from different networks (eg xxxcoin and bitcoin) at
the same time?
A: No, cgminer keeps a database of the block it's working on to ensure it does
not work on stale blocks, and having different blocks from two networks would
make it invalidate the work from each other.

Q: Can I configure cgminer to mine with different login credentials or pools
for each separate device?
A: No.

Q: Can I put multiple pools in the config file?
A: Yes, check the example.conf file. Alternatively, set up everything either on
the command line or via the menu after startup and choose settings->write
config file and the file will be loaded one each startup.

Q: The build fails with gcc is unable to build a binary.
A: Remove the "-march=native" component of your CFLAGS as your version of gcc
does not support it.

Q: Can you implement feature X?
A: I can, but time is limited, and people who donate are more likely to get
their feature requests implemented.

Q: Work keeps going to my backup pool even though my primary pool hasn't
failed?
A: Cgminer checks for conditions where the primary pool is lagging and will
pass some work to the backup servers under those conditions. The reason for
doing this is to try its absolute best to keep the GPUs working on something
useful and not risk idle periods. You can disable this behaviour with the
option --failover-only.

Q: Is this a virus?
A: Cgminer is being packaged with other trojan scripts and some antivirus
software is falsely accusing cgminer.exe as being the actual virus, rather
than whatever it is being packaged with. If you installed cgminer yourself,
then you do not have a virus on your computer. Complain to your antivirus
software company. They seem to be flagging even source code now from cgminer
as viruses, even though text source files can't do anything by themself.

Q: Can you modify the display to include more of one thing in the output and
less of another, or can you change the quiet mode or can you add yet another
output mode?
A: Everyone will always have their own view of what's important to monitor.
The defaults are very sane and I have very little interest in changing this
any further.

Q: What are the best parameters to pass for X pool/hardware/device.
A: Virtually always, the DEFAULT parameters give the best results. Most user
defined settings lead to worse performance. The ONLY thing most users should
need to set is the Intensity for GPUs.

Q: What happened to CPU and GPU mining?
A: Their efficiency makes them irrelevant in the bitcoin mining world today
and the author has no interest in supporting alternative coins that are better
mined by these devices.

Q: GUI version?
A: No. The RPC interface makes it possible for someone else to write one
though.

Q: I'm having an issue. What debugging information should I provide?
A: Start cgminer with your regular commands and add -D -T --verbose and provide
the full startup output and a summary of your hardware and operating system.

Q: Why don't you provide win64 builds?
A: Win32 builds work everywhere and there is precisely zero advantage to a
64 bit build on windows.

Q: Is it faster to mine on windows or linux?
A: It makes no difference. It comes down to choice of operating system for
their various features. Linux offers much better long term stability and
remote monitoring and security, while windows offers you overclocking tools
that can achieve much more than cgminer can do on linux.

Q: My network gets slower and slower and then dies for a minute?
A; Try the --net-delay option.

Q: How do I tune for p2pool?
A: It is also recommended to use --failover-only since the work is effectively
like a different block chain, and not enabling --no-submit-stale. If mining with
a BFL (fpga) minirig, it is worth adding the --bfl-range option.

Q: I run PHP on windows to access the API with the example miner.php. Why does
it fail when php is installed properly but I only get errors about Sockets not
working in the logs?
A: http://us.php.net/manual/en/sockets.installation.php

Q: What is a PGA?
A: At the moment, cgminer supports 3 FPGAs: BitForce, Icarus and ModMiner.
They are Field-Programmable Gate Arrays that have been programmed to do Bitcoin
mining. Since the acronym needs to be only 3 characters, the "Field-" part has
been skipped.

Q: What is an ASIC?
A: They are Application Specify Integrated Circuit devices and provide the
highest performance per unit power due to being dedicated to only one purpose.

Q: Can I mine scrypt with FPGAs or ASICs?
A: No.

Q: What is stratum and how do I use it?
A: Stratum is a protocol designed for pooled mining in such a way as to
minimise the amount of network communications, yet scale to hardware of any
speed. With versions of cgminer 2.8.0+, if a pool has stratum support, cgminer
will automatically detect it and switch to the support as advertised if it can.
If you input the stratum port directly into your configuration, or use the
special prefix "stratum+tcp://" instead of "http://", cgminer will ONLY try to
use stratum protocol mining. The advantages of stratum to the miner are no
delays in getting more work for the miner, less rejects across block changes,
and far less network communications for the same amount of mining hashrate. If
you do NOT wish cgminer to automatically switch to stratum protocol even if it
is detected, add the --fix-protocol option.

Q: Why don't the statistics add up: Accepted, Rejected, Stale, Hardware Errors,
Diff1 Work, etc. when mining greater than 1 difficulty shares?
A: As an example, if you look at 'Difficulty Accepted' in the RPC API, the number
of difficulty shares accepted does not usually exactly equal the amount of work
done to find them. If you are mining at 8 difficulty, then you would expect on
average to find one 8 difficulty share, per 8 single difficulty shares found.
However, the number is actually random and converges over time, it is an average,
not an exact value, thus you may find more or less than the expected average.

Q: My keyboard input momentarily pauses or repeats keys every so often on
windows while mining?
A: The USB implementation on windows can be very flaky on some hardware and
every time cgminer looks for new hardware to hotplug it it can cause these
sorts of problems. You can disable hotplug with:
--hotplug 0

Q: What should my Work Utility (WU) be?
A: Work utility is the product of hashrate * luck and only stabilises over a
very long period of time. Assuming all your work is valid work, bitcoin mining
should produce a work utility of approximately 1 per 71.6MH. This means at
5GH you should have a WU of 5000 / 71.6 or ~ 69. You cannot make your machine
do "better WU" than this - it is luck related. However you can make it much
worse if your machine produces a lot of hardware errors producing invalid work.

Q: What should I build in for a generic distribution binary?
A: There are a number of drivers that expect to be used on dedicated standalone
hardware. That said, the drivers that are designed to work generically with
USB on any hardware are the following:

Code:

--enable-avalon
--enable-avalon2
--enable-avalon4
--enable-avalon7
--enable-bflsc
--enable-bitfury
--enable-cointerra
--enable-drillbit
--enable-hashfast
--enable-hashratio
--enable-icarus
--enable-klondike

Q: How do I use the --decode function to decode a pool's coinbase?
A: You need to have a bitcoind with server functionality and pass it the
credentials as the first pool in your config, and pass the pool's address that
you wish to decode as the second pool configured. Note the bitcoind NEEDS the
http:// prefix.

e.g.:
./cgminer -o http://localhost:8332 -u user -p pass -o solo.ckpool.org:3333 -u 15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ --decode

---

This code is provided entirely free of charge by the programmer in his spare
time so donations would be greatly appreciated. Please consider donating to the
address below. Driver development for new ASIC only bitcoin hardware can be
suitably sponsored.

Con Kolivas <kernel@kolivas.org>
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ