Common information about SkinClub Provably Fair system.
Table of contents
1. Main terms explained
2. Why do we need it?
3. How it works
3.1 Public hash (generating and purpose)
3.2 How a roll is generated
3.3 General work principle of PF on our website
4. The reasons to trust it
4.1 Potential vulnerabilities
4.1.1 Selection of a server seed
4.1.2 History change
4.1.3 Variety of chances
4.1.4 High complexity for an ordinary user
4.1.5 Selection of a public hash
4.1.6 Decoding a public hash
5. FAQ
5.1 What is a pseudo-random function?
5.2 Why is changing the nonce enough for the randomness of the numbers?
1. Main terms explained
Seed — a string used as the input data for the pseudo-random number generator.
Server seed — a seed generated by the server, which is hidden from the user (hashed) at the moment of opening the case and which can be revealed after the new server seed has been established.
Client seed — a seed generated by the user, which can be changed by the user at any moment.
Secret salt — a specific string used to protect the server seed, so that it could not be decoded by users, consequently used while generating a public hash.
Public hash — a string (hash(server seed + salt)), which is always available to users and guarantees that the server seed has been unchanged.
Example: “50d858e0985ecc7f60418aaf0cc5ab587f42c2570a884095a9e8ccacd0f6545c”.
Nonce — a serial number representing the number of times server seed has been used, thus, allowing the server seed not to be changed every time.
Roll — a pseudo-random number given in a fixed interval, which is obtained from the server seed, the client, and the nonce. Later it is used to define the prize for the winner.
Odds Range — a current filling of the case with all the ranges and prices labeled.
Range — an inclusive interval, which defines the roll needed to win a certain prize (a skin in the case and others).
2. Why do we need it?
As we know, users tend to have some sort of mistrust to the websites, which use online platforms to sell various things. Some of them can change the odds in such a way that certain users (bloggers and other public figures) will have a higher chance of getting a good prize, thus, allowing them to popularize these websites for the sake of higher profits. Sounds not really fair, right?
Provably Fair (PF) is the tool, which can be used to “spill the beans” of such websites, revealing the odds, numbers, and other parameters.
Hence, it guarantees that the website uses transparent politics and all the chances are equally random and fair. Moreover, an interesting thing about this technology is that you won’t be able to predict your future outcomes of the gamblings, however, you will be able to check previous wins, thus, seeing that all the winnings and losses were absolutely fair. To predict future numbers, you will have to know, which pseudo-random algorithm is used and which input data was involved. As previously told, you won’t be able to know these parameters at the moment of opening the case, but you will be able to see them after the session.
3. How it works
Basically, there are 3 values used as input data for the session (server seed, client seed, and nonce), which consequently produce 2 outcome values (public hash and roll), used to define the prize and verify fairness.
In simple words, a server seed, client seed, and nonce produce the roll, which is the final value used to choose the item for the winner. As it is seen, the s.s., c.s., and nonce are the input values for the algorithm, while the roll is the outcome, which is randomly generated and can be checked by the user. Sounds a bit complicated? Don’t worry, we’ll get into this step by step.
So, first of all, let’s make it more clear about the 3 input values (server seed, client seed, and nonce):
Server seed as it was told before is generated by the server and hidden from the user unless he/she decides to check the credibility of the gamblings. If the user decides so, then the server seed is revealed and the new one for future gamblings is established. Also, server seeds update every time the nonce value reaches 500. This is needed for the sake of safety.
Client seed, on the other hand, is generated by the user and can be changed at any time (as well as server seed could be revealed). The opportunity to change client seed is done to illustrate that the server seed is credible and was not chosen to change the odds.
Nonce in other words is linked to the current server seed and basically can be considered as a counter of how many times this server seed has been used. Besides, it allows us to use the same client seeds and server seeds to produce different rolls, which is a part of the transparency policy.
Thus, now you should have a better understanding of these 3 terms.
Having discussed some fundamental concepts, let’s think of an interesting aspect occurring because of it. Although it is said that server seed is used in the algorithm, the user is not able to know it before the session. “Why?” — you might think. Well, simply because if everybody knew the server seed beforehand and it continued remaining the same during the next sessions, they would be able to predict future rolls, making the gambling predictable and not fair at all.
This is the moment, where a public hash makes a big sense.
3.1 Public hash (generating and purpose)
As it was told before, the public hash is a significant part of the Provably Fair mechanism. So what is it exactly and why is it useful?
Remember we talked about that if a user gets access to the server seed the gambling becomes unfair? The problem here is that the user wants to know that the server seed has not been changed, however, the website cannot show it to prove it. Instead, to justify that the server seed remains unchanged, the user is given in some term a mold of the server seed — the public hash, which is sort of a derivative of the server seed.
Thus, a public hash is basically the hashed version of the server seed. But the hashing process here requires some “salt”, i.e. before hashing the server seed is joined to some string data to make it almost impossible to unhash it. In some way we may say that it is simple encryption, however, there are some differences, which do not need to be discussed here.
Hence, a public hash guarantees you that the server seed that was used during the session was the one that was claimed. You may even check it by yourself after the session since the results of hashing the same server seed would be the same. If the public hash of the website differs from your result of hashing the server seed (with salt), this means that PF was violated.
You see it is not so hard, isn’t it?
In case any user want to check fairness of our code we suggest to use some service like https://www.freeformatter.com/hmac-generator.html. There you should paste server seed to the “String” field, salt to the “Key” field, select “SHA256” algorithm and click “Compute”. As a result “Computed HMAC” must 100% match your public hash, congratulations!
3.2 How a roll is generated
In this part, we will be talking about some technical processes. Namely, the detailed process of generating a roll will be shown.
To obtain a roll, before this we need to obtain another parameter, let’s call it “Key”.
To make it simpler, Key is a long string obtained using the encryption method sha512 HMAC, where the message is the server seed, and the secret key (needed for hashing) is ClientSeed-Nonce data (two values concatenated, with a dash as a separator). So far so good?
The result of this hashing (Key) is a long hexadecimal string, which will kind of define your destiny. From that Key we would take first 15 symbols, convert them from base 16 to base 10 number — outcome. Now we take remainder of division of the outcome by MaxRollNumber (i.e. 100,000 for case opening) and that gives us the roll value in range [0; MaxRollNumber-1]. The last step is a pure decoration — let’s increase roll by 1 in order to shift it’s range to [1; MaxRollNumber]. After this, the roll can be used for various functions, such as defining the prize.
3.3 General work principle of PF on our website
Now, having analyzed the hardest work principle part, let’s see what it looks like from the perspective of a user.
On the website, there is a section “Provably fair”, which can be easily entered by a user. On this page he/she may see all the seeds used on the website before, moreover, to see/copy all public hashes in order to verify them later.
So, as for the gambling process, when a user opens a case, the roll is calculated. After this, depending on the range which had been appointed by the roll, the item is given to the user. In addition, users may see all the item ranges(Odds range) there. Also, it is possible to see the roll-ID, using which we can see how the roll had been calculated, why a certain item was given, and manual validation data. As we see, it does make sense.
4. The reasons to trust it
As we may see from the name itself (Provably Fair), the main idea of this technology is to allow users to check the credibility of the gamblings at any time. Namely, it indicates that the prizes and outcomes are purely random and fair.
Moreover, users can be sure that no intervention has been done during the session. Cryptographic algorithms used by the system allow it to produce a uniform distribution of numbers, making it more safe and reliable (confirming histograms are available in our public Google Colab page).
Even though the algorithm is made in such a way that guarantees a 100% fair policy, still it is a simple producer of random numbers in the hands of website owners. Therefore, the technology itself cannot provide a full guarantee to users, that is why all the systems involved need to work in synergy with other systems.
However, what are the possible theoretical issues of PF?
4.1 Potential vulnerabilities
4.1.1 Selection of a server seed
The first vulnerability is that in theory, in a reasonable time, it is possible to calculate such a server seed that can be used with certain client seeds to predict gambling outcomes. In this case, the PF mechanism will display not random values, but values in a desirable range during the first 3 or 5 sessions, which use the same server seed. Sounds unfair, isn’t it?
Moreover, this might be both a minor problem (if the server seed changes very rarely) and a major problem (if the s.s. changes too frequently, e.g. every 10 or 30 uses).
4.1.2 History change
Secondly, since all of the historical data such as seeds, generated values, rolls, and other information is kept on the website, it can be easily changed in a favorable way (there are no blockchain technologies that could reveal this). This creates certain “holes” on websites, allowing to rewrite the initially falsified information, consequently representing an unfair mechanism as a fair and reliable one.
In theory, this should not be a problem. Because all of the information is public, it can be easily kept under control. However, in practice, there is no systematic control among the community and there are almost no users who pay attention to it. Just think of it, have you ever tried to conduct such a check by yourself or collaborate with other members to do it? Most probably the answer is “no”. Thus, as we can see most users simply take it on trust.
4.1.3 Variety of chances
Thirdly, although the PF algorithms make the data public, it does not guarantee that somebody will not create UX in such a way, that bloggers and ordinary users will have significantly different odds at gambling. Of course, this can be revealed during cross-checking, however, this demands frequent collaborative checks by the community, which presumably will not ever be organized. Moreover, it is possible to eliminate the possibility of public checks on the website at all.
The solution suggested is to create a well-planned and clear UX, where the users may transparently see all the odds, also, having an opportunity to check not only their sessions but also of other people.
All mentioned features were implemented on the Skin.club and it is worth noting that the majority of our competitors don’t have some or any of them.
4.1.4 High complexity for an ordinary user
Another aspect of vulnerabilities is connected to the complexity of the PF mechanisms. Even having read lots of pages about this, a significant part of users may still be struggling to understand it fully. We are not talking about some elderly people at the end of their retirement, who surprisingly open cases so far, we are also talking about the majority of youngsters. Ordinary people, like you and us. Some sense of magic may still be present somewhere in the deep. This means that even though this mechanism guarantees the credibility of the website, lack of social understanding, proper certification, and audits’ work may still allow the website owners to implement various scam schemes, pretending to be using fair mechanisms. For instance, some communities suggest the story of “Skinhub” as illustrative (do not confuse it with beloved Skin.club 💜).
4.1.5 Selection of a public hash
Here we will take a look at the theoretical possibility of deceiving users. In short, it is possible to make up a different pair of server seed and salt, which after being hashed would display absolutely the same public hash, that was publicly announced. However, in practice, it would require substantial financial spendings ($50–100k per month) and the work of highly qualified professionals, which in the end would bring quite a doubtful profit.
4.1.6 Decoding a public hash
This is an interesting one, especially in terms of finances. This is the vulnerability that can be described as a theoretical possibility to obtain the server seed from the public hash. This is easy to understand, however, incredibly hard to implement. The thing is that this process would be so complicated, that it might require such financial expenditures as $100–200k for a single reverse. In theory, it is possible, in practice the possibility is almost zero.
As the organizers of our website, we have made this attack impossible, since we add “salt” while hashing server seeds (makes unhashing substantially costlier), also, have limited maximal nonce.
5. FAQ
5.1 What is a pseudo-random function?
In fact, all of the computer functions that are called “random” are actually pseudo-random. This means that a certain seed is taken as an input, which is consequently exploited by the algorithm to produce some set of numbers. Moreover, having the same input data, a mechanism always provides the same results. This is the aspect that made it possible to implement the mechanism of checks for users.
5.2 Why is changing the nonce enough for the randomness of the numbers?
This question might be eliminated if we take a look at the example below.
Let’s take two almost identical input data, where the last symbols only differ.
E.g.:
- 55b887b84772377e4f8fe668_f961fde4ef7ebd29b1b5b01a_1
- 55b887b84772377e4f8fe668_f961fde4ef7ebd29b1b5b01a_2
You see, the only difference seen here is in their last symbols. The difference might seem so negligible (less than 0.0001%), however, it produces significantly different hashes after hashing (you may check). This occurs due to the property of cryptographic functions called “avalanche effect”. That rule fundamentally guarantees that any small changes in the input data (such as server seed) would produce different and random results on the outcome without any correlation with the change.
