ITs up to people to trust an unknown source or not;  but any supporting evidence would be help in banning the perpetrators and associated binaries...  So I suggest you take clear notes of what web addresses/sockets that binary is communicating to;  as that is a means to verify the claim through 3rd party testing.


I myself compile XMR-stak with the devfee and devfee URL's removed;  and I don't have 70 pages of history/reviews... but in the end, its about being from a trusted source is why people have used my binaries to be frank.

In the same note;  I have had countless people try and piggyback their builds onto my thread;  which I quickly delete and have none of that;  because I have no idea who they are, and what is in their binary.



Be aware;   Most miner apps now;  that tend to contain standardized code structures for lets say SHA256 type hashes which are an integral part of many many different algos;  will show up as a trojan/virus merely due to that signature that is common with the malware miners that have been around in the past (ones you don't know are on your machine, or ones run in the background of a website, etc.).    My xmr-stak binary also fails some virus scan protections for the very same reason.....  You yourself can actually compile the same source;  with the very same changes I have made (which I would happily provide); and see that your binary will indeed carry the same false detection.

Compiled and uploaded version 2.8.2.  For full release notes, please visit FireIce-UK's Github.

If you have issues with this version when upgrading from 2.7.x, delete your config files (.txt), and try again.


This version does not support the new upcoming fork of Monero;  the algo change has not been publicly released yet.  It does however support forks on other coins, as well as some new coins/algos.   Please see the github mentioned above for more info.

The math and methodology from what i have seen seem is pretty sound....   and sounds about right in the end.....   I have been thinking of taking my personally used builds of XMR stak;  and randomizing the initial nonce somewhat....   I have doen this to other miner apps int he past with good results;  better overall average hashrates.   

I know its partially a placebo thing;  but, if everyone starts in a different portion of the race, they stand less chance of crashing into each other


But this fork will scream louder than any words.   All previous forks have.... and this one, being quiet about its changes until the final week;  is a smart thing;  as long as the devs have a working and tested algo at the time of release; and don't supply a devfee'd out binary/source (which they have not as of yet).

Other binary producers will have to scramble to update themselves;  but honestly;  this will help immensely in the end; and i am 100% for it.

Through this whole algo cycle till today;  I have had 1.2-1.8Kh/s on the monero network; and will continue to keep faith in it.    Privacy coins have been under scrutiny and attack for a bit now.... there's a reason for that....

scam? no.  not unless they didn't deliver a product as advertised.


This hardware release proves one thing:  The day I commented when XMR had almost doubled in diff over the course of a few hours; and the subsequent plunge in price from sell-offs right afterwards,  I knew a massive asic had been produced; and shitmain was the most likely culprit.


Anyone who buys this thing;  deserves what they get.   Especially knowing they are trying to buy a specific hardware solution that is made to work on a coin that specifically will reorganize to invalidate such devices.




Bitmain uses the devices behind closed doors with nondisclosure.   This is shady activity; and its your fault for buying into it.

This has been covered extensively many times in this thread.

If the pool hasn't mined enough to pay in that coin,  it does not exchange for that coin;  it waits for it to be mined and sells your earnings at current market rate in the system to people requesting BTC as payment.  This is why it is suggested to use BTC as payment; as you aren't waiting for enough to get paid.  There are many warnings in many places about this.

BUB.   Pennies a day.

Yeah, Atom PC's work well too;  but the most ECO and $ friendly solution ive found is using a RPi.

I use nanopool.   It hasn't done me wrong in the slightest.

yes; the constant disconnects and reconnects for the pool add up in lost time with no mining for either side.   And if your internet connection isn't the greatest, the effect is compounded.

I suggest if you like the app; that you donate to the creator instead of using the devfee method... its cleaner for both parties.

download the original executable package from the github repository.

see this link for notes on adding those DLL files since they are compiled under Cuda 8.5 I believe.... check fireice's build notes.

The app checks for different versions of the libraries now; and they have appropriate filenames.  Should be straightforward.  LMK if you have trouble.   His DLL worked for my 4-series GTX cards.

100% accurate.


Its been a bug thats been around ever since the first weeks of zpool when this new exchange pool code was released.

Restarting the miner app;  has it pop back up on the list.  It is the only solution found thus far, as its a very tough type of bug to track down.

The best way to keep track of your miners is through configuring API access to each one;  and a miner control/monitoring utility/os of some sort; which there are many out there.

I appreciate the detailed answer;  It should help people make a decision for sure.

you beat me to it.  just use a USB HDD for the blockchain storage.  Rpi is cakework for staking machines.

If you can get a free VPC (AWS or something similar), then you can use that sort of service as well.  I believe Max Lee uses VM's on the web in datacenters for his staking wallets.

im going to be the skeptic;  don't take it the wrong way.


Why arent you doing this? :

Things such as currently working bitstreams, guarantee of algos that will be available by what date (specifically) as well as hash to power figures.... 

As of this point;  in this day and age;  you should have at least a physical demo and review of the hardware verified by a heavily trusted member before taking in any funding....   as in the past;  taking in funds before us seeing some actual results on this website from a trusted reviewer, has almost always resulted in disaster of many different levels and proportions.


At first glance, I see a big up front hardware cost;  with no promise of return other than a stated interest in algos (no word on active development or working hashing bitstreams for instance...);  especially since you mention algos that are constantly changing to be as asic/FPGA resistant as possible...  we aren't not even any sort of efficiency datum or anything;  just a spec sheet for a publicly sourceable fpga.

The hardware looks like it should be very versatile; and it looks like the product as shown is a sound concept/design.. but;  you are asking a bunch of people to jump off a cliff right now without knowing if there's a parachute attached to their back while boarding the plane.

I hope you understand my concern, and its meant in the best of light to help you succeed.   These are the main red flags I have to share and ask about.

Look at "CPU threads conf" section.

notice every other core is being used.

Create the new entries for the missing cores.

It may or may not be more efficient.   My I3-6100 CPU only configures for 2 cores;  but it has 4 threads....   If I create the extra configs, it doesn't gain a noticeable amount of hashrate, and actually I get less performance on the GPU's in the system as a side effect.

I believe it has to do with the two threads being tied to each core;  thus 16 "cores" with 32 threads....  but im not sure about your processor, im just giving an example.  It may or may not increase or decrease your performance.

I mentioned this the day the diff skyrocketed to what it is right now (it almost hit double diff) and price shortly thereafter took a big dive of a large percentage.

A 4 month algo change commitment would be ideal for XMR IMHO.   It would leave just enough time for development of a hardware specific solution before that solution would become invalidated.   The only real weak link at that pint would be the devs and sharing of these algos too early before network-ready release...  if they can stay honest in that regard, im sure the coin would be pretty much the ideal form of "asic resistant".

A big part of that resistance, is identifying hardware/FPGA that could be easily used to circumvent the new algo's anti-asic strong points.     At some juncture (probably at that point now TBH):  memory will not be a strong point of an algo any longer.  We truly need to find a way to make time an integral function of the hash.   Create a speed-limit "time base" and have it conform to that.  If you pull time to an equal playing field;  then having more speed simply does you nothing.  SSL uses time as a part of it's validation scheme; and I hope in the future, some sort of likeness to this concept comes to fruition.

This is pretty accurate.  I have one of these boards; and I never had any issues with any of the PCIE slots.  The only time was when I was trying to have too many onboard devices and too many GPU at the same time.

Try the above;  and try just a primary GPU in that slot with nothing else (1x-16x riser necessary)

When I oil my fans, I just reach for an old tin of sewing machine oil.  Pretty thin, does the job.

https://bitcointalk.org/index.php?topic=3264773  This miner supports all CPU's and GPU's.   I am even getting older 500-series nvidia cards to mine.  To use the older cards, you need the cuda 8 .DLL file from the official release;  as my build is with CUDA 10, not supporting older 500 series cards and earlier.  There are clear notes on this in the thread linked.

I use nanopool myself.  They are reliable.   If you set your payout to .3 XMR, youll get regular payments every few days with current network diff.

The miner linked above, I compiled myself and it has open-source, as well as I removed the devfee.  AFAIK, its the most current version I have compiled and posted; but I haven't checked in a while.  (Windows version)  People usually post in the thread telling me there's a new version and I jump on it when able after that.... since my XMR rig is a "set and forget" machine;  I rarely think about touching it.  It's rather self sufficient.

Neither;  it's programmable nature is its inherent flaw;  with either coin.   Likened to Adobe Flash in a loose manner of speaking.   This is the specific reasoning I have never trusted ETH, or any fork thereof.   The DAO "hack" and now this;  is more than enough for me to be happy about my past decision and reasoning.   It's not an attack on any particular coin or person's own thoughts;  its simply a fact of my own reasoning.


This would be the case; if the chain reorganizations and 51% attack weren't happening... there is a reason for the absurd reward... you obviously haven't kept up with all the news surrounding this.  I suggest you do a little research as to whats been happening other than "some asshat spending a ridiculous amount of gas fees".

The why of the 'thing';  is the most important link to understanding the 'things' nature as a whole.


*edit* apparently the hacker has returned some stolen funds to different accounts;  so says yobit's twitter.... hmmm.  suspicious.

This is the problem with ETC/ETH itself that I have wondered about;  it's nature as a programmable thing.... and interconnectivity with it's token...   room for potential problems like this.  He must have found a way to initialte a TX to run a malicious code, or abuse some aspect/vunerability of ETC we don't understand yet.  Another curious notion, is could it be done with ETH as well (this being a test case for ETH which has a much greater market share)...