I'm going to use the Radeon HD 7970/R9 280X as my primary example here, as I have access to those GPUs and they actually work so far on all of the N-Factors...provided you have the right settings. Let's go over those here, just for fun.
Approximate Settings for Scrypt-Jane Mining
|
|||
| N-Factor | Settings | R9 280X | R9 280 |
| 4 | -I 18 -thread-concurrency 20480 -g 1 | 6.1MH | 4.8MH |
| 5 | -I 18 -thread-concurrency 20480 -g 1 | 4.5MH | 3.7MH |
| 6 | -I 18 -thread-concurrency 16384 -g 1 | 3.3MH | 2.5MH |
| 7 | -I 18 -thread-concurrency 16384 -g 1 | 1.8MH | 1.5MH |
| 8 | -I 18 -thread-concurrency 8192 -g 1 | 1.0MH | 850KH |
| 9 | -I 18 -thread-concurrency 8192 -g 1 | 550KH | 470KH |
| 10 | -I 18 -thread-concurrency 8192 -g 1 | 330KH | 270KH |
| 11 | -I 12 -thread-concurrency 8192 -g 2 | 133KH | 100KH |
| 12 | ? (I missed this stage of YAC/YBC) | ~70KH | 55KH |
Starting at the initial N-Factor of 4, you can expect pretty amazing hash rates -- about 6.1MHash/s from the 280X, with TC at 8192 and intensity 18-20. Six days later you switch to NF 5 and your hash rate will drop to around 4.1MH, still with more or less the same settings. At NF 6 you'll drop to maybe 3.3MH, then NF 7 is going to be around 1.8MH, NF 8 drops yet again to 1.0MH, and so on. Along the way, however, you'll start to find that the settings that worked well for lower N-Factors no longer run without hardware errors at higher N-Factors -- and never mind what happens after about NF 12, where hash rates seem to drop far more than the 30-50% of earlier changes.
You'll need to tune the above settings a bit in most cases to get accepted shares and no HW errors -- in particular, I had a lot of problems not getting HW errors on the R9 290X at lower N-Factors. I also know that HD 5800 and HD 6900 hardware basically suck at scypt-jane (scrypt-chacha) for reasons I don't quite understand. Probably it's just the OpenCL code isn't really tuned for those older cards, or maybe the older hardware just lacks certain features, and that's fine. Still, it's interesting to look at how performance at the different N-Factors compares. As far as I know, scrypt-jane with NF-9 is basically regular scrypt, but hash rates are lower by around 20% compared to vanilla scrypt. At NF-10, again hash rates are lower than Scrypt-N by 15% or so.
One of the things I wanted to mention in all of this is that the initial stages of scrypt-jane are basically a headache for larger mining operations. Depending on how similar your hardware is, you could be looking at a few hours to perhaps a day or two of tuning and tweaking settings to get things running "properly" at each N-Factor adjustment. And if you're not paying close attention to all your rigs, you might come back from a weekend to find that all your PCs basically accomplished nothing after the latest N-Factor adjustment -- been there, done that, and didn't particularly care for the hassle, thanks! At least the rate of NF change slows down a lot at NF-14, but then at that point you're looking at rather low hash rates and there may be better coins to mine.
It's not too surprising then that most new "clone" coins that are moving away from vanilla scrypt are going with Scrypt-N (Adaptive-N-Factor Scrypt, as defined initially by Vertcoin). Sadly, VTC doesn't seem to be getting as much credit as it deserves, at least in terms of trade value, but then part of that might be due to the somewhat lackluster name and logo. There are at present at least seven cryptocurrencies I can name off the top of my head that use Scrypt-N, compared to six scrypt-jane options (though I'm probably missing some from both sides). The first scrypt-jane coins are already at NF-14, and frankly they've struggled since NF-13 with GPU mining; in a few months we'll see NF-15 and then three months later we'll hit NF-16. They might become predominantly CPU-mined coins at that point, which may or may not be a bad thing.
In short, Scrypt-N makes more sense to me from many perspectives. It skips the early (and somewhat chaotic) low N-Factor stages, it defines a more systematic progression from one N-Factor to the next, and in my experience at least it runs better on several generations of hardware. That doesn't mean it will necessarily succeed (see Betamax vs. VHS), but as more and more scrypt ASICs arrive and GPU miners look for greener pastures, I suspect the majority will end up with Scrypt-N (or something new). What will that be? I'm not quite sure, but as always I'm keeping an eye on things. If you'd like to subscribe to my email newsletter for more information on what I'm mining, you can find the instructions on this page.
I can only count 7 Scrypt-N coins. VTC, Panda, EXe, Emu, genesis, gpu, ya
ReplyDeleteWhich ones do you know of ?
Well, I said "seven", and you've got most of them. The only one you missed that I know of right now is 10-5, and I'm not sure which coin you're talking about with "ya" -- YAC is actually scrypt-jane. :-)
ReplyDeleteFirstly thanks for all the great crypto information - love reading your blog!
ReplyDeleteI think the DarkCoin algo (X11) is another ASIC resistant algo that offers great potential. Maybe you could consider doing a write-up on your thoughts around anonymity and or taking a look at the X11 algorithm?
http://www.darkcoin.io/downloads/DarkcoinWhitepaper.pdf
X11 is basically different from Quark, Scrypt, SHA256, SHA3 (Kekkac), Hefty, etc. But I'm not sure X11 is really ASIC resistant -- it was ported to GPUs at least within a month or so of its release. That said, Darkcoin is at least better than the hundreds of scrypt clones. :-)
DeleteThere's also Altcoin, lol. It gained no traction, but was the first scrypt-N coin after Vertcoin.
ReplyDeleteAs time goes on I'm inclined to disagree with you about scrypt-N being better than scrypt-jane. The problem with scrypt-jane is the N-factor change, but it's also its strength. Soon multipools will start destroying scrypt-N coins, but with scrypt-jane all the coins are on different schedules.. That said, I think it would make the most sense for a scrypt-jane coin to alternate between a few chosen N-factor values (maybe 8-10) rather than progressing to 14, where it's basically unminable with GPUs. Hopefully somebody will make such a coin soon (I've been considering it, but day job and parenthood really cut into the time I can spend on side projects).
I honestly don't have a problem with multipools -- coins should be designed with the knowledge that multipools exists and may jump on/off mining. Difficulty should adjust more quickly, which is a big issue with old coins like BTC and LTC waiting 2016 blocks between adjustments. As for scrypt-jane sticking with a few (lower) N-Factors, the problem with that is it makes ASICs a possibility, which is why VTC started at N=10 (regular scrypt is N=9). If you want to avoid ASICs for the time being, you need to be at N=10 or higher.
DeleteASICs will be possible, sure, but until they're actually a reality it doesn't matter as much with scrypt-jane, considering that different hashing/mixing functions are in use. I see no reason not to wait until ASICs for an algorithm are seen in the wild, then release an update to counter it. It's a cat and mouse game for sure, but I think a reactive approach would work better considering that the ASIC designers are less capable of anticipating your next move.
DeleteThe problem with updating a coin to prevent ASIC mining is that you need to do a hard fork, and to have that happen you need 51% of the hashing power of the network to update to the new fork. Early on (esp. when there are bugs), that's easy. When a coin is established, however, and when there are ASICs mining a coin, keeping non-ASICs at 51% or more could prove difficulty. Basically, a hard fork late in the game that only serves to counteract new mining hardware could easily kill a coin.
Delete