Just over a year ago, we launched our first open-source software project for Bitcoin mining: Braiins OS. The necessity of an open-source operating system for ASIC miners became apparent with the covert AsicBoost fiasco of 2017 (which we talked about here), but it was going to be important regardless of that incident. With so few competitive HW manufacturers building ASIC machines for Bitcoin, providing a transparent alternative to the factory firmware increases decentralization in what is perhaps the most centralized part of the entire industry.
Cgminer is a multi-threaded multi-pool FPGA and ASIC miner for Bitcoin. Cgminer is a popular app in this category but like many, it requires advanced users for the most part. You might want to start by reading the following included text documents; API-README, ASIC-README, and FGPA-README. Released in 2011, this program is still one of the most popular mining software options available today, thanks to its compatibility with three different mining hardware: ASIC, FPGA, and GPU. CG miner is an open-source Ethereum miner written in C and comes with support and binaries for OpenWrt routers, RPi, and more.
However, Braiins OS is only one component of the full Bitcoin mining stack. Our greater ambition when we began this project was to make the full stack open-source, standardized, efficient, and secure. That means addressing the other components of the stack: CGminer and stratum protocol. We’ll share an update about the latter in a future post, but for now we’ll focus on the alternative we’ve developed to replace CGminer, which we call BOSminer.
Background on CGminer
CGminer started out as an open-source CPU miner that anybody could run. With the introduction of GPU mining in late 2010, we began to see some of the open-source parts of the miner disappearing. Each GPU variant had special pieces of the GPU kernel being developed, and only a fraction of them were made open-source right away. The general community was stuck using whatever happened to be available.
FPGAs were the next evolution of mining hardware, but not much changed when it came to this CGminer component. Some people made their code open-source, while others did not.
Then, in late 2012, ASICs entered the market and quickly began to dominate SHA-256. ASICs are embedded devices, which means that they contain a special (rather than general) purpose computing system. The typical ASIC architecture consists of the following:
Typically, you have a control board with an FPGA and a CPU running some form of Linux on it, and then you have some hashing boards with mining chips that perform the actual Bitcoin mining work. The role of the control board in this architecture is to continuously feed the chips with the right amount of new mining work. Originally, CGminer was utilized for this purpose. Over time, however, manufacturers shifted logic away from CGminer into the FPGAs on the control board.
The best-known example of this is what we mentioned above: the AsicBoost incident with Antminer S9s in which the FPGAs were between the CPU and the hashboards, enabling AsicBoost functionality covertly. The manufacturer essentially prevented the use of AsicBoost because the code in the controller was intentionally wrong and it wasn’t documented. Some CGminer source code was available, but it would just generate bad solutions and was practically useless.
In the present, we need an FPGA and a microcontroller to drive the hashing boards. The CGminer has become essentially just a disorganized and severely limited front-end for the FPGAs. In fact, it reached a point where even the engineer who created it, Con Kolivas, had to stop supporting it.
At last. Cgminer changed mining, but its time is over. Glad, as it ended up being a mess of commercial forks that often didn't provide their code and were plagued with bugs and backdoors that I couldn't fix even if I modified my code. I lost interest in supporting it. Good luck. https://t.co/8Q3aotbNMW
— Dr. Con Kolivas (@ckpooldev) September 5, 2019At the same time, ASIC architecture is such now that CGminer itself isn’t enough to run the whole system because it’s running some Linux. So you need drivers, bootloaders, etc. to actually run it — which are also typically closed-source. Even when manufacturers say that they’re complying with the General Public License (GPL), it’s still up to individuals to try to collect all the pieces of software and somehow patch them together to get a full system image running. Simply put, it’s a mess.
Lack of Open-Source Today
There are so many exciting open-source projects being developed throughout the Bitcoin ecosystem these days, but mining has unfortunately been lagging behind. Given incidents like the Antbleed miner backdoors and covert AsicBoost, we decided that it was about time to do something about this. Obviously it’s complicated because there are various types of mining devices and the different manufacturers often wouldn’t publish their modifications to the CGminer codebase (violating the GPL).
That’s why we started developing the Braiins firmware for mining devices. And one of the more interesting things about that is that we decided to write our software in Rust programming language, which is turning out to be a challenging but rewarding decision.
Why We Chose Rust
Having extensive experience with embedded development, we knew that this was going to be a serious challenge no matter which language we choose. With that being said, Rust is a modern programming language with a handful of properties that make it ideal for this kind of application:
1) Memory safe
Rust performs the majority of its safety checks and memory management decisions when it’s compiling. As a result, it’s better protected from software bugs and other security vulnerabilities relative to non-memory safe languages when it comes to memory access.
2) Suitable for embedded devices
There are no other prominent programming languages that are compiled and strongly typed and that have no runtime. Rust has no runtime, no virtual machine handling memory management — everything is statically compiled. And it’s much more lightweight than, say, C++. All of those things make it very suitable for embedded devices like ASICs.
3) Code reusability
Unlike most other languages, with Rust we know that if something compiles for a device, then chances are that the same code component can be reused on the server side. That’s great, because it allows use to share once code base for the hosts and embedded devices, which simplifies testing as well as production.
4) Packaging system
Rust is pretty unique in that it allows you to use different versions of the same code package simultaneously. In other words, we can run two versions of the same library in a compiled image, which would be practically impossible if, for example, we were using C or C++.
5) Built-in test harness
Generally speaking, developers don’t like to write tests. You see that with CGminer, where none of the manufacturers are contributing test cases. Rust comes with a nice test harness, so you can simply run “test” and check that there are no regressions in the code..
6) Bright future
There’s something to be said for the fact that companies like Microsoft, Amazon, and many others are heavily investing in the further development of Rust. It makes sense to choose a technology with a bright future ahead of it. Plus, that means there should be a more reusable code, which can save us a lot of time in future development.
The Difficulty of Hiring Rust Developers
The first challenge we faced after deciding to use Rust was simply the scarcity of engineers who could work with it. Braiins is based in the Czech Republic, and there simply aren’t that many Rust developers walking around looking for work. (Take note, computer science students 😉). There’s certainly a growing interest in Rust and we had several people on our team who were ready to take on the challenge of learning it, but it took many months to reach the point where we were productive enough in the codebase to start generating original code in-house. (And by the way, we’re still hiring engineers.)
Choosing Between Multithreading vs. Async Programming
Once the decision to use Rust was made and we had a competent team in place, it was time to start designing the software. This is the fun part, of course, but it comes with more difficult decisions and challenges.
One of the first decisions we had to make was how we were going to divide our computation into tasks. There are two options:
Multithreading
This is a well-established method where you have libraries and you create threads to synchronize them. The codebase for this is very solid in Rust. However, multithreading doesn’t scale if you’re receiving many requests on your network (as is the case with Bitcoin mining), and having a lot of threads slows you down because it’s a full task in the OS sharing the same address space.
Async
The async approach requires more thought up-front, but it can scale amazingly well on a single thread. We already had some engineers who have worked with node.js, and it’s easier for us to find developers that think in terms of async programming. The drawback of async is that it’s invasive to your software design — it contaminates everything and seeps through the layers. So you have to constantly be aware of that as you design the software.
Ultimately, we saw that the async approach was going to pay off in the long-term. At the time, however, the async framework for Rust wasn’t quite where we would have liked it to be. (If you look at this website, you can see the current state of things. Depending on when you’re reading this, it may actually be async … but as of writing there are still a couple things missing. Still, the standard library has matured enough and all of the async keywords are stable, so we felt comfortable to take the async path.
This was just one of dozens of decisions and challenges we’ve faced so far in writing this software in Rust, but we can’t concisely cover it all in this post. If you’re curious to hear more about the design process, stay tuned for a video of Jan’s full talk at Dev++ in Tel Aviv. (It should be posted around mid-October.)
Timeline for Moving from CGminer to BOSminer & Stratum V2
We’ve been working on two important pieces of the Bitcoin mining stack in parallel, which are BOSminer and Stratum V2. A nice side effect of this is that we’ve been able to include a Stratum V2 simulator in the BOSminer prototype which we released for developer testing. Next up on the agenda is to add a V2 proxy (written in Rust) as well so that we can simulate various possible deployment scenarios.
Meanwhile, we’ll be taking developer feedback and improving on BOSminer for the following months in order to release an alpha version in December, ultimately followed by a fully-fledged release around March 2020. You can see more details in the timeline below.
Once the fully-fledged BOSminer is released, it will make it significantly easier for us to add support for different ASIC machines in the future, such as the latest Whatsminer M20S and Antminer S17. Considering that, we are currently committing the majority of our effort and resources towards making BOSminer a reality within the timeframe shown above.
Cgminer Download
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.
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:
USB menu:
Pool menu:
Change settings menu:
Display menu:
On exiting:
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
—
Cgminer Official Website
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.
Cgminer Windows
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
Multiminer
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:
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.
Cgminer 4
Con Kolivas <kernel@kolivas.org>
15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ