This is not Mrs. Scrypt, as they are in no way married to each other. In fact, that would be rather incestuous, because they are related. Now, I’m not sure what the laws in your state/country say about incestuous marriages, but in the crypto world it’s a big no-no. You should treat this crypto lady with dignity and the respect she deserves.
Scrypt-Jane is like any girl, she likes to have a good time. Her, and her mix functions and algorithm buddies will take you to exotic locations! What, you’re not following? Pardon me, I’ll explain.
Scypt-Jane supported no less than three different mix functions. Get your dancing shoes on right now! First up, we have Salsa20/8. Swing those hips guys, come on, lighten up a little bit. Salsa 20/8 is actually a pretty simple function : it takes a 64-byte String (a line of letters or words), and converts it to a 64-byte String Salsa20(x). Not making sense, am I? Fine, I’ll try to be less theoretical. Salsa20 consists of two parts : a stream cipher to encrypt data (this should sound more familiar to all of you), and a compression function (called Rumba20) to compress a 192-byte String to a 64-byte String. In layman terms: you can have a longer line than 64 bytes, as long as it’s below or equal to 192 bytes, it will be compressed (read : converted) to a line of 64 bytes later on.
Now that we are all warmed after some Salsa and Rumba, it’s time to introduce the second mix function : ChaCha20. I’m honestly not making this up people. ChaCha20 is much like Salsa20 : it’s also a stream cipher. However, it offers some neat extras, such as increasing resistance to cryptanalysis. It also improves time per round. The easiest way to express this is : if you’re mining on a pool, you see that one mining “round” (time until the pool finds a block) can take either a long or a short time. The durations of these rounds are partially influenced by the ChaCha20 mix function of Scrypt-Jane. There are other factors influencing this too, but we’re not going there right now. Just trying to keep it simple to understand.
Last, but not least, is the third mix function. You passed the Salsa for beginners chapter, so it’s time for some advanced moves with Salsa6420/8. Sexy name, isn’t it? Salsa6420/8 is a proof-of-concept 64-bit version of Salsa20/8. It’s just a better version of Salsa20/8 which allows for bigger byte blocks. I could go into more technical details, but half of you would fall asleep, and the rest would start playing games on their smartphones, so we’re not going to bother with that. Just remember there are 3 mixing partners in Scrypt-Jane, you won’t have to fill this in on a test or anything! Or will you…..?
Back to reality folks! Scrypt-Jane also supports several hash functions. One of them is very well known by all of us now, SHA-256. It also supports SHA-512, but that will be covered in a later article called “Oddballs”. Other supported hash functions include BLAKE256/512 , Skein512 and Keccak256/512 (or simply SHA-3). The latter one will also be covered in aforementioned article “Oddballs”.
BLAKE256-512 is a very simple design to implement, and relies on previously analyzed components, the HAIFA structure (we won’t cover this at this point) and the ChaCha core function (which we have touched on earlier in this article). The most prominent features about BLAKE are having a high security margin (pretty important, but I shouldn’t have to point this out to you by now), and high performance versatility (which is also very important to us miners). The one things to remember about BLAKE is that it can and will be faster than SHA-2(56) on a number of platforms.
On the other hand , we have Skein512. Who comes up with these gorgeous names anyway? They should be awarded a medal…But I digress, apologies. Skein is a hash function, which has been submitted in NST’s cryptographic hash algorithm competition. It combines speed, security, simplicity and flexibility. We all love that, don’t we peeps? It’s also very efficient on a variety of platforms, both in hardware and software environments. You can find the Stein algorithm on something as little as a smart card, something most of you have experience with.
But enough of the theoretical background, let’s take a look at what Scrypt-Jane can do for us. You may or may not know this, but Scrypt-Jane does it’s own variant of scaling difficulty. Scrypt-Jane uses an N-Factor (which is a number), and that number determines the amount of memory required to solve a share. This N-Factor number will go up at certain intervals, usually when a certain block number has been found in the blockchain. Whenever this N-Factor number increases, the mining efficiency will lower, because more memory is required to complete the same task performed before. In simple terms : the number of accepted shares will drop, as will your earnings.
Scypt-Jane was originally intended to be mined on CPU’s only, but we wouldn’t be in the Cryptocoins world unless someone found a way to circumvent that. There have been GPU miners circling around for Scrypt-Jane coins , to increase our mining efficiency, and earnings. Now, you may think that, even if the earnings diminish, you’ll be able to mine with your GPU for a longer period of time compared to CPU mining? That’s where you’re wrong , I’m afraid. Eventually, the N-Factor will be so high, that GPU’s will be less efficient than CPU’s for mining Scrypt-Jane. You didn’t see that one coming, did you? In that regard, Scrypt-Jane is not like SHA-256 or Scrypt.
In my closing statement, I want you to take a look at some of the Scrypt-Jane coins that we have seen so far. One of the first Scrypt-Jane coins that got some traction was Yacoin, however, that traction has been lost with most miners I’m afraid. More recently, we have seen coins like Copper Bars
source: http://majesti.co/cryptonerd/crypto-terminology-101-scrypt-jane-part-3/
Guugll Search
http://www.guugll.eu/scrypt-jane/
No comments:
Post a Comment