Cgminer

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 hash rate without networking delays yet minimise connection overhead.

• It's an open-source GPU-miner based on its original code. This tool works with AMD and NVIDIA graphics cards and features proxy support and a number of tools to overlock GPU and take control over coolers' speed. Mine SHA-256 cryptocurrencies and Litecoins. Download CGMiner 4.10 from our software library for free.
• Start mining with CgMiner using Awesome Miner. Awesome Miner can be used with any mining pool. The list below includes the predefined pools to make it easier to get started with mining on the most popular pools.
• CGminer is a command line application written in C. It’s also cross platform, meaning you can use it with Windows, Linux and Mac OS. The software includes overclocking, monitoring, fan speed control and remote interface capabilities, among others.

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.

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

At 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. Soncview driver download for windows 10. 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

Cgminer Setup Guide

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.

‍

Not Given

Ok – this works!

I’m using latest sdk & amd drivers APR-2015.

This is the only miner to work with any amount of success, that I’ve seen. (Litecoin), and I’ve tried half a dozen versions. Including 4.x.x.

Some example scores from my Alienware laptop:

C:cgminer-3.7.2-windows>”My Miner2.bat”

Best Bitcoin Mining Software

C:cgminer-3.7.2-windows>setx GPU_MAX_ALLOC_PERCENT 100

SUCCESS: Specified value was saved.

C:cgminer-3.7.2-windows>setx GPU_USE_SYNC_OBJECTS 1

SUCCESS: Specified value was saved.

C:cgminer-3.7.2-windows>cgminer –scrypt -o xxxxxxxxxxxwemineltc.com:3333 -u xxxxxxxx.1
-p xxxxxx–lookup-gap 2 –thread-concurrency 7200 -I 14 -g 1 -w 128 -T
[2015-04-14 03:29:10] Invalid config option –kernel: Cannot specify a kernel with scrypt

[2015-04-14 03:29:10] Started cgminer 3.7.2
[2015-04-14 03:29:10] Loaded configuration file cgminer.conf
[2015-04-14 03:29:10] Error in configuration file, partially loaded.
[2015-04-14 03:29:11] Probing for an alive pool
[2015-04-14 03:29:11] Pool 1 difficulty changed to 127.999023
[2015-04-14 03:29:11] Pool 0 difficulty changed to 127.999023
[2015-04-14 03:29:12] Switching to pool 1 stratum+tcp://hk3.wemineltc.com:3333 – first alive pool

[2015-04-14 03:29:12] Pool 0 stratum+tcp://hk3.wemineltc.com:3333 alive, testing stability

[2015-04-14 03:29:12] Switching to pool 0 stratum+tcp://hk3.wemineltc.com:3333
[2015-04-14 03:29:15] Network diff set to 41.6K
[2015-04-14 03:29:21] Accepted 379d8238 Diff 1.18K/128 GPU 1 pool 0
[2015-04-14 03:29:46] Accepted 012d0e23 Diff 218/128 GPU 1 pool 0
[2015-04-14 03:29:51] Accepted 012317bb Diff 225/128 GPU 0 pool 0
[2015-04-14 03:29:53] Accepted 019374e5 Diff 162/128 GPU 1 pool 0
[2015-04-14 03:29:56] Pool 0 difficulty changed to 45
[2015-04-14 03:29:56] Pool 1 difficulty changed to 45
[2015-04-14 03:30:01] Accepted 04fdce8c Diff 51/45 GPU 1 pool 0
[2015-04-14 03:30:06] Accepted 0154b634 Diff 192/45 GPU 1 pool 0
[2015-04-14 03:30:09] Accepted 011d7642 Diff 230/45 GPU 1 pool 0
[2015-04-14 03:30:10] Accepted 04434536 Diff 60/45 GPU 1 pool 0
[2015-04-14 03:30:16] Accepted 4f69ef04 Diff 825/45 GPU 0 pool 0
03:30:25] Accept(5s):498.7K (aved 04e1fab9 Diff 52/45 GPU 1 pool 0 g ) : 5 6
[2015-04-14 03:30:43] Accepted 035551ae Diff 77/45 GPU 0 pool 0
[2015-04-14 03:30:45] Accepted eb151da8 Diff 279/45 GPU 0 pool 0
[2015-04-14 03:30:56] Accepted 058ce311 Diff 46/45 GPU 0 pool 0
[2015-04-14 03:30:57] Accepted 04419eea Diff 60/45 GPU 0 pool 0
[2015-04-14 03:30:59] Accepted 2a5a06f7 Diff 1.55K/45 GPU 0 pool 0
[2015-04-14 03:31:02] Accepted 055164ec Diff 48/45 GPU 1 pool 0
[2015-04-14 03:31:03] Accepted 04c17a2b Diff 54/45 GPU 1 pool 0
[2015-04-14 03:31:04] Pool 0 difficulty changed to 103
[2015-04-14 03:31:04] Stratum from pool 0 detected new block
[2015-04-14 03:31:04] Pool 0 stale share detected, submitting as user requested

[2015-04-14 03:31:05] Rejected 04ad516e Diff 55/45 GPU 0 pool 0 (unknown-work)

[2015-04-14 03:31:27] Accepted 01e00bd4 Diff 137/103 GPU 1 pool 0
[2015-04-14 03:32:01] Accepted 68b1ed62 Diff 626/103 GPU 0 pool 0
[2015-04-14 03:32:11] Accepted 019a0871 Diff 160/103 GPU 0 pool 0
[2015-04-14 03:32:18] Accepted 01c07dd4 Diff 146/103 GPU 1 pool 0
[2015-04-14 03:32:19] Accepted 021330c3 Diff 123/103 GPU 0 pool 0
[2015-04-14 03:32:20] Accepted 5db174f4 Diff 699/103 GPU 0 pool 0
[2015-04-14 03:32:21] Accepted 8d3f44e3 Diff 464/103 GPU 0 pool 0
[2015-04-14 03:32:25] Accepted 018443f2 Diff 169/103 GPU 1 pool 0
[2015-04-14 03:32:30] Accepted 01b80682 Diff 149/103 GPU 1 pool 0
[2015-04-14 03:32:50] Stratum from pool 0 detected new block
[2015-04-14 03:33:00] Accepted 01e56656 Diff 135/103 GPU 0 pool 0
[2015-04-14 03:33:07] Accepted 0182db98 Diff 169/103 GPU 0 pool 0
[2015-04-14 03:33:19] Accepted 0148b614 Diff 199/103 GPU 0 pool 0
[2015-04-14 03:33:24] Accepted 0b68706d Diff 5.75K/103 GPU 0 pool 0
[2015-04-14 03:33:33] Accepted c5575f43 Diff 332/103 GPU 1 pool 0
[2015-04-14 03:33:51] Accepted d9ee6db7 Diff 301/103 GPU 1 pool 0
[2015-04-14 03:34:02] Accepted 01d1e9dd Diff 141/103 GPU 0 pool 0
(5s):586.0K (avg):567.0Kh/s | A:2745 R:45 HW:12 WU:501.0/m