Good morning, everybody!

As some of you may have heard there’s currently a certain “buzz” of excitement around the monero community, all relating to the upcoming “hard fork” – and though it’s actually surprising to must just how little is yet known about this upcoming change, I wanted to at least assure everybody that yes, of course I will update lukMiner to work with this hard fork.

Why is this “hard fork” such a big deal?

Now before saying anything else, let me go a bit into why this hard fork is such a big deal. Hard forks are nothing new to altcoins, and in fact, most coins are just  forks of a very small family of core algorithms (e.g., Monero, ETN, Sumo, etc are all just variants of the same cryptonight algorithm). Even for a given coin, hard forks are not necessarily a big deal: Yes, sometimes these hard forks lead to “splitting” of coins if only some of the community adopt these changes – e.g., ZEC (ZCash) and ZCL (ZCash Classic), or ETH (Ether) and ETC (Ether Classic) are both the effect of a given coin (e.g., ETH) having hard forked, and some continuing to mine the old, “classic” coin on the old blockchain with the old algorithm; while others use the new code on the new, “forked” blockchain. It’ll be interesting to see if this’ll happen to monero, too; though at least right now it looks like at least in this instance it probably won’t (we’ll see).

Even if it does not lead to a real “fork” into different coins, hard forks in a given coin’s codebase are nothing new – Monero alone had 6 or so in the past, and usually they’re not too big a deal: usually it’s some sort of bugfix or vulnerability fix that can’t be done in a backwards-compatible way; it usually gets adopted by everybody that runs a node, and that’s it. No big deal.

Now this time, unfortunately, the changes that are being discussed relate not only to the code affecting the nodes themselves, but to the actual hashing algorithm behind monero itself. In particular, this has two really big implications: First, it means that it will affect everybody that mines monero: If only the node code changes (as in the past) then it’s only those that run their own nodes that have to update; and in times where you pretty much have to use a pool, anyway, that means the burden on updating in the past was almost entirely limited to pool owners. This time, it’s the miners themselves that have to change; and it’s not only the all the miner developers (such as I) that have to change their codes, but also all the actual miners (i.e., you) that have to update to those new versions. So if you’re reading this, be prepared that you will have to update to the respective version of lukMiner as soon as this hard fork takes effect (and no, I do not know when that will be, yet).

The second big change – and maybe even more of a pain in the … ah, backside … that most people seem to not even have realized yet is that this means that this probably you will no longer be able to interchangeably miner different cryptonight coins with the same hashing algorithm: In the pre-fork world, the same miner could mine both XMR, ETN, SUMO, NiceHash, BXN, and a ton of other codes. The upcoming change however is a change to Monero, not to the cryptonight algorithm itself, and as such, it’s totally unclear which other coins (if any) will adopt this change. That sounds benign, but probably isn’t, as it creates all kinds of “collateral damage” questions: For example, will Nicehash switch its “cryptonight” over to the new Monero algorithm? Or will they (have to) add an additional algorithm just for Monero? (And if they do, what about all those NiceHash users that bought cryptonight hashes to mine monero?). Or in fact, does Nicehash even still make sense if you can no longer trade the same hashes for the most profitable coins?. It’ll have similar questions for sites like WhatToMine (can no longer compare different cryptonight algorithms), etcpp. Lots of questions, and so far, few answers.

Even for us devs, there’s a lot of potential “collateral damage”: For example, right now I can steer all my dev shares to dwarfpool, because it doesn’t matter which coin the users mines; the hashes are the same. After the hard fork, I (as well as every other miner dev) will have to track different accounts, and send the dev shares accordingly. Not a big deal, you say … BUT: what if somebody keeps on mining with older version of a miner that hasn’t been updated yet? As long as he mines only coins that haven’t changed he’s fine – but suddenly, lots of “wrong” shares will be routed to the (old) dev share accounts, which I’m sure DwarfPool won’t be all too happy about….

Anyway; the fork is going to happen, and despite all my whining above it’s probably a good thing: ASICs do take a long time to develop, test, tape in, test again, produce, test again, and ship; while software can be changed in a few minutes. As such, changing the mining algorithms – albeit but slightly – will be a very good deterrence against ASICs, and that in itself is a (very) good thing. I’d wish for a bit more transparency and information about very basic questions like “what actually will change … and when?” – but overall, it’s still a good thing. (And please note, it’s also a good thing for you, the users: The biggest threat to your investment in CPUs, GPUs, and Phis for mining is ASICs!).

Upcoming Changes to LukMiner

So, enough of that whining – what does it mean for you, the users? First of all, yes, I most certainly will produce a version of lukMiner that will adapt to the hard fork. And yes, I’ll do that as soon as anybody can tell me what the changes will actually be (so far the Monero devs don’t answer, and there’s no changes in the public codebase visible, yet, even in branches). But it likely won’t be much that’ll change – if all you want is thwarting an ASIC the changes could be trivially small – so I fully expect to have a fixed version the same day I get info of what those changes are. After all, I have a fair amount of machines running on both Nicehash and specific “classic” cryptonight coins (ETN, SUMO), and (currently) all my dev shares on Monero… so even if it wasn’t for my own commitment to you, the users – I’d better have something quick.

Second, I will likely change the miner to no longer have different binaries for aeon vs xmr vs new-xmr, vs xyz; and instead have a single miner that can select the algorithm on the command line (there’s already way too many different binaries; I don’t want have yet another). Most likely, this will take the form of “-coin <name>”, where “name” will be name of the coin to miner (eg, xmr for monero, aeon for aeon, etn for Electroneum, etc). Eventually I’ll also try to merge in all the different opencl vs mpss vs cpu vs phi vs knl binaries into only two different binaries … but that can wait. Either way, you’ll have to update your mining scripts. (I’ll post detailed info as soon as I release the updated miner).

So; enough for today. Bottom line: Big changes are coming; let’s see how they’ll play out – but overall they’re probably for the long-term good; and I’ll certainly support them from day one. With that:

Happy Mining!