Monday, February 17, 2014

Everything You Wanted to Know about Scrypt-Jane

I've talked a bit about a few scrypt-jane based coins previously -- specifically I've mentioned Microcoin, but there are several others. I've also talked about the alternative Proof of Work (PoW) algorithm used in Vertcoin, "Scrypt Adaptive N-Factor". Put simply, I like the VTC algorithm a lot more, but I've never really discussed why. So, this is as good a time as any to broach that subject.

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
As you can imagine, running the scrypt algorithm with N-Factor of 20 would require a huge chunk of RAM even on a CPU with eight threads -- 1GB just for the basic memory footprint. On a GPU like the R9 290X that has 2816 shader cores and 4GB RAM, any N-Factor above 13 is going to present some real problems. Now, let's get back to VTC's Adaptive-N vs. scrypt-jane.

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:
  1. Calculate the number of seconds since the launch of the coin.
  2. 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.
  3. 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).
  4. Using the numbers from steps two and three: NFactor = ([BinSigDigits - 3] * 170 + [{ThreeMostSigBinDigits & 0b11} * 25] - 2320) / 100
  5. 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)
Personally... I think that's a stupid set of N-Factor progressions. There, I said it: the standard scrypt-jane implementation has non-sensible spacing between some of the N-Factors. Take the first 48.5 days when we're below N-Factor 10 as a prime example; what purpose does it serve to use such low N-Factors? Well, early on the GPU mining speed in scrypt-jane will be much higher compared to CPU mining, whereas once you hit N-Factors of 9 and above it starts to slow down. At that point, we're still only looking at 15-50 days between some pretty severe adjustments in hash rates from 10-13, which just creates a bit of chaos. Then round about N-Factor 14, we reach the point where CPUs become roughly as fast as GPUs, give or take -- we've actually got a real example of this, as YACoin is already at N-Factor 14 -- and then we start to slow down on the N-Factor changes.

So here's the question: is a coin that's predominantly limited to CPU mining a good thing? While I'm happy to mine such coins when it makes sense from a profitability standpoint, I generally assume that any good coin that sticks around long enough will end up with a GPU miner port, unless it's simply impractical to make one. But if the algorithm is simply not portable to GPUs for whatever reason, I don't inherently think that it's a bad thing. My problem with scrypt-jane is that it sort of goes the opposite route: it starts out by opening the floodgates for GPUs, but then after six months or so (194 days), we reach N-Factors where GPU mining becomes quite slow. That will result in most if not all GPUs leaving to go to "greener pastures", which is sort of the opposite of what you want to happen.

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.
GPU Perf.
(HD 7970)
Difficulty BTC Rate BTC/Day
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
So it's worth pointing out that the start times for the various coins determine when the N-Factor changes; Microcoin has a start time of 1389028879 (06 Jan 2014 17:21:19 GMT) while Ultracoin has a start time of 1388361600 (30 Dec 2013 00:00:00 GMT), so UTC is currently one N-Factor ahead of MRC. As for YAC and YBC, other than their reward structures they're both close enough in start times that they're on N-Factor 14. Also, I couldn't find a CPU miner that didn't hard-code the start time so I couldn't test CPU rates on MRC and YAC (yet -- if you have a binary for Windows, let me know).

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
UTC: Uj1rnV4fZBPAngTj7xcYHrRcxKkadRiqGo
YAC: Y1xTeeJFnwawaCPVHcvhH23w5oDGy1VRgC
YBC: Yg6wWEd2fcMyMcxbQ3eGg3dXo5aYs878pt


  1. That's a lot of hate for scrypt-jane! I could be wrong, but I thought scrypt-jane used different hashing and mixing functions than normal scrypt? I thought I had heard somewhere it was Keccak for the hash function... I do agree with you on the NFactor changes being a problem with scrypt-jane though.

    1. I noted this at one point (see "Truth be told..." paragraph). But as implemented, scrypt-jane is just whacky. Which is why Vertcoin's Adaptive-N-Factor is basically superior IMO. I think we'll start to see more VTC-style close as well (a la Panda 2.0, which is a subject for another blog post. LOL)

      Basically, scrypt-jane itself isn't bad, but the implementations in YAC, YBC, UTC, MRC, and probably every other coin that clones one of those basically needs to rethink things.

  2. Enjoy reading your site/comments, always very informative with facts & figures not fanboys & fiction so please piss freely on or in any pool/coin/site you care to as I for one greatly appreciate the lack of bs here ;)

  3. I'll send you a little UTC for the explanation, I've had no luck harping on the forums asking for one.

  4. Yep, really nice blog. Full of useful informations.
    Here's a small tip ! (0.011111111 BTC)

  5. One more question, how do you know what the N-factor is for a given coin at any given time?

    1. For the scrypt-jane coins I've looked at (YAC, YBC, UTC, MRC), the code to calculate nFactor reads as follows:

      // Ultracoin: increasing Nfactor gradually
      const unsigned char minNfactor = 4;
      const unsigned char maxNfactor = 30;

      unsigned char GetNfactor(int64 nTimestamp) {
      int l = 0;

      if (nTimestamp <= nChainStartTime)
      return 4;

      int64 s = nTimestamp - nChainStartTime;
      while ((s >> 1) > 3) {
      l += 1;
      s >>= 1;

      s &= 3;

      int n = (l * 170 + s * 25 - 2320) / 100;

      if (n < 0) n = 0;

      if (n > 255)
      printf("GetNfactor(%d) - something wrong(n == %d)\n", nTimestamp, n);

      unsigned char N = (unsigned char)n;
      //printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfactor));

      return min(max(N, minNfactor), maxNfactor);

      If you don't know code, basically that's what I try to explain above the N-Factor table. So based on the number of real-world seconds elapsed since the start of the coin, it gives you an N-Factor of 4 to 30. For VTC and PANDA, N-Factor is coded to change at specified intervals that are much more spaced out, but it starts at N-Factor 11. Does that help?

    2. I can read the code, I couldn't find that bit on the github anywhere though, thanks.

    3. Typically this stuff is in Main.cpp -- as a former programmer, some of the code I've looked at is really bad. LOL

  6. So we should be mining Microcoin now and just hold it for a few months? Or ultracoin?

    1. Looking at the current and future block rewards i would prefer microcoin.

    2. Yeah, Microcoin is a bit weird with the rollout schedule, but at least it wasn't premined/instamined. The first 10K block were pretty much worthless, and now they're getting to be worth quite a bit (117K or so right now). When it gets back to being 10K for a while and higher N-Factors are in play, I suspect price will go up to at least 10-15 satoshi. Maybe that's too ambitious, but I'd say the current 2-3 satoshi is too low for just about any coin. Guess we'll see.

      Ultracoin is already into higher N-Factor and more difficult to GPU mine, but it has been moving up to the 0.0006 range during the past day for some reason (pump and dump?). The UTC block rewards are honestly a lot more sensible than MRC's rewards, but that means you have to stick with it longer.

  7. Your 7970 in the comparison is pretty slow...There are ways to get higher hash rates, like for instance lookup-gap implementation in cudaminer. 5.33 kh/s on my GTX 780 is a walk in the park.
    I consider yacoin to be a pretty interesting coin, and like to support it., and it's still profitable if you know how to tweak the miners.

    1. I was going off of readily available information; if it's possible to get 3-4 times better performance on YAC than what I posted above, it actually might not be so bad to mine right now. But even at 0.008 BTC per day that's less than several other coins I could name.

  8. Everything about scrypt jane.....and no word about proof of stake. AFAIK have all scrypt-jane coins out a pos component. Microcoin implements real pos after block 310K, this is an important factor for mining now and future mining as well as coin security imho, but that was completly ignored here.

    1. True -- but I thought PoS was separate from scrypt-jane? Anyway, the odd thing is that scrypt-jane really isn't the above performance necessarily, but it's what four scrypt-jane coins all use. I think tweaking the N-Factor schedule would be one of the first things to adjust if you were cloning a scrypt-jane coin.

      As for PoS, in general I'm not sure I really like the idea. I guess I haven't really looked into it too much, but the idea of getting more of a cryptocurrency simply because you already have a bunch of coins that you're not even spending is a bit at odds with getting cryptocurrencies to be useful. Maybe I'll devote some time to the subject later, though.

    2. Seperate sure, but as every coin has it just worth mentioning i think. For microcoin it changes everything regarding mining in the long run. Most coins will be mined in some months and hasrates will drop because of the low and steady block rewards then. Security has to come from pos from this point at least partially, or you will be an easy target for 51% attacks. And there are many ways to implement pos, you may have to be an active node for some time or similiatr, i would really like if you take a deeper look into it and perhaps write an article about.

  9. Hi Jarrad, does Scrypt-Jane uses less energy? I am mining Radioactive coin which uses scrypt-jane and I noticed that the temperature is easy to control compare to mining VTC. for the same fan speed the temp is 5C lower than mining VTC so does it mean it's more energy efficient? (I haven't attached my kw meter but looks like it saves a bit)

    BTW, radioactive coin is a good coin maybe you can have a look and study about it?:) It needs more attention.


    1. The amount of energy being used is basically going to vary depending on how hard the GPU is working. Usually scrypt is going to do a pretty good job of maxing out your GPU, but maybe at different N-factors scrypt-jane will use more/less energy than the current scrypt and VTC N-Factors.

  10. I was playing around with commands in the debug window today on UTC and the "getmininginfo" reports an N-factor of 10 for UTC.