Fundamentally, the difference between scrypt-jane and VTC's Adaptive-N-Factor PoW algorithms is pretty simple. VTC basically went with hand-picked dates for when to move on to various higher N-Factors, while most coins using scrypt-jane have a formula that decides when it's time to move up the difficulty ladder. In fact, VTC actually adjusted it's rollout schedule in a hard-fork of the blockchain after the first couple of weeks, at the same time they introduced KGW.
But I'm getting ahead of myself. First, I suppose I ought to quickly cover what N-Factor is used for. N-Factor represents the amount of data that a thread works on, with the N in N-Factor being the power of two (minus 1) that's used. Standard scrypt uses and N-Factor of 9 (I think? Correct me if I'm wrong and I'll fix the table!). Here's the quick list of RAM requirements (poached from the VTC announcement thread):
| N-Factor | N (2N+1) | Memory |
|---|---|---|
| 9 | 1024 | 128KB |
| 10 | 2048 | 256KB |
| 11 | 4096 | 512KB |
| 12 | 8192 | 1MB |
| 13 | 16384 | 2MB |
| 14 | 32768 | 4MB |
| 15 | 65536 | 8MB |
| 16 | 131072 | 16MB |
| 17 | 262144 | 32MB |
| 18 | 524288 | 64MB |
| 19 | 1048576 | 128MB |
| 20 | 2097152 | 256MB |
| 21 | 4194304 | 512MB |
| 22 | 8388608 | 1GB |
| 23 | 16777216 | 2GB |
| 24 | 33554432 | 4GB |
With Vertcoin, the rollout of the above N-Factors has been set such that we start at N-Factor 11, we'll move to N=12 February 25, 2016; N=13 comes in September 30, 2017, and so on. The reasoning is that right now, scrypt ASICs are just starting to show up, and they're all built for N=10; to make a new ASIC for N=11 will require a solid 6-12 months at least -- assuming you can find a company that thinks it's even worth doing, considering N=12 will supplant N=11 -- and it would require a lot of RAM. And in the meantime, those with GPUs can still do a decent job of mining.
Truth be told, scrypt-jane doesn't actually define any schedule -- it's just a flexible implementation of scrypt that can be tweaked as desired. It supports several mixing and hashing functions, with scrypt being used with a varying N-Factor. In general, scrypt-jane implementations have set a minimum N-Factor of 4 and a maximum N-Factor of 30. That's fine, but the problem is how coins are scaling the N-Factor. Here's what happens with YACoin, YBCoin, Ultracoin, and Microcoin to name several that I've checked:
- Calculate the number of seconds since the launch of the coin.
- Look at that number in binary, and basically find how many significant binary digits are used, but don't count the three most significant digits.
- With those three most significant binary digits, do a logical AND operation with 0b11 (or in other words, look at the two least significant bits).
- Using the numbers from steps two and three: NFactor = ([BinSigDigits - 3] * 170 + [{ThreeMostSigBinDigits & 0b11} * 25] - 2320) / 100
- The result is converted to an integer and limited to values between 4 and 30, inclusive.
That's one of those formulas that just doesn't seem too sensible to me, and the code unfortunately doesn't shed any light on why these numbers were selected. Why 170, 25, 2320, and 100? As my computer science instructor used to call such numbers: GOK (God Only Knows). This is why we have constants defined in code, so that you can give a short comment on what the number is used for. Bad coding practices unfortunately are par for the course in the cryptocurrency world. So what does this formula actually mean? Well, it means the N-Factors will be changed on the following time schedule:
| N-Factor | Seconds Since Launch | Days at N-Factor |
|---|---|---|
| 4 | 0-524287 | 6.07 |
| 5 | 524288-786431 | 3.04 |
| 6 | 786432-1048575 | 3.0 |
| 7 | 1048576-1835007 | 9.1 |
| 8 | 1835008-2097151 | 3.1 |
| 9 | 2097152-4194303 | 24.2 |
| 10 | 4194304-5242879 | 12.2 |
| 11 | 5242880-8388607 | 36.4 |
| 12 | 8388608-12582911 | 49 |
| 13 | 12582912-16777215 | 48 |
| 14 | 16777216-33554431 | 194 |
| 15 | 33554432-41943039 | 97 |
| 16 | 41943040-67108863 | 292 |
| 17 | 67108864-100663295 | 388 |
| 18 | 100663296-134217727 | 388 |
| 19 | 134217728-234881023 | 1166 |
| 20 | 234881024-268435455 | 388 |
| 21 | 268435456-536870911 | 3107 |
| 22 | 536870912-805306367 | 3107 |
| 23 | 805306368-1073741823 | 3107 |
| 24 | 1073741824-1879048191 | 9320 |
| 25 | 1879048192-2147483647 | 3107 |
| 26 | 2147483648-4294967295 | 24855 |
| 27 | 4294967296-5368709119 | 12428 |
| 28 | 5368709120-8589934591 | 37283 |
| 29 | 8589934592-12884901887 | 49710 |
| 30 | 12884901888+ | (Indefinitely) |
The typical progression is usually the opposite. We start with a CPU-only coin (BTC started this way, and so did LTC, QRK, and now DRK). After the coin/algorithm gains some momentum, smart people figure out a way to use GPUs to speed up the work. More time passes and if the coin(s) using the PoW algorithm remains viable, maybe people even try to make an FPGA or ASIC for the core algorithms. If you want to stop this sort of progression, well, honestly you can't truly stop it -- all you can do is make it more difficult. Remember that scrypt was originally created to be a CPU-only PoW, but that failed. Quark and X11 have now been ported to GPUs with varying degrees of success. Considering GPUs are becoming more like CPUs, at some point in the future it's not a stretch to assume that if something can't be mined (effectively) with a GPU, it probably can't be mined with a CPU either.
Wrapping up, I wanted to quickly look at the most common scrypt-jane coins and check on hash rates profitability -- for CPUs as well as GPUs. This is obviously just a snapshot in time, but going with the four coins mentioned earlier (which are similar in most respects in terms of PoW implementation, though the block reward schedules vary), here's what we have (as best as I can tell -- again, correct me if I'm wrong as it's a bit tricky to find the current N-Factor for most of these coins):
| Coin | N-Factor | CPU Perf. (i7-4770K) |
GPU Perf. (HD 7970) |
Difficulty | BTC Rate | BTC/Day (CPU / GPU) |
|---|---|---|---|---|---|---|
| Microcoin | 10 | ? | 450 | 2.319 | 0.00000003 | ? / 0.0134 |
| Ultracoin | 11 | ? | 235 | 6.828 | 0.00034 | ? / 0.0118 |
| YACoin | 14 | 0.97K | 1.4K | 0.0167 | 0.000031 | 0.00184 / 0.00258 |
| YBCoin | 14 | 0.97K | 1.4K | 0.119 | 0.0037 | 0.00191 / 0.002^8 |
The short summary: YAC and YBC are mostly not worth your CPU/GPU time, while for the time being MRC and UTC are doing okay. MRC will have a lot of coins, and the current exchange rate fluctuates around 2-4 satoshis, so you can see pretty large swings in value over the course of a single day. If you want to dump a bunch of MRC, you'll probably get 2 satoshi whereas being patient can get you 3 or 4 satoshi.
The big problem with mining any of these is that the scaling N-Factor happens so early that if you're not in before N-Factor 12 or so, you've missed the boat for GPUs. Which means if you are in early enough, holding the coins for the first 100-150 days or so (until we reach N-Factors of 12) isn't a bad idea. Check back in a couple months and I'll let you know how that strategy worked out for me!
Wrapping this up, sorry if I'm pissing any anybody's favorite pool, but I call it as I see it. There have been plenty of questionable coins released in the past year, and while early adopters have often made out with big winnings, johnny-come-lately is often left wasting their time and energy on a dead-end coin. Plus, I had some people ask about Ultracoin in particular (since it's relatively new), and this post is a result of my looking into that topic. What's really sad is the state of many of the coin releases, with poorly documented code that was clearly just cloned from another coin and tweaked as little as possible. Anyway, we'll see which coins are still around in another year and being actively mined; until then, happy (scrypt-jane?) mining!
Donations welcome
MRC: 1Ctnz6cHcMYiF9fz2pyd6orFuo1mDhKdWj
BTC: 153qS9Ze32hnV3fwirZLWNka4wBAowc21E
LTC: LfCLyykrNFftzpdWejR73hf478ZtBzQ9jE
VTC: VaYNYUUi3amUTKQAQSs9EM4xJyNRyqnoUG
UTC: Uj1rnV4fZBPAngTj7xcYHrRcxKkadRiqGo
YAC: Y1xTeeJFnwawaCPVHcvhH23w5oDGy1VRgC
YBC: Yg6wWEd2fcMyMcxbQ3eGg3dXo5aYs878pt