[Request] Help understanding this Provably Fair function

[ltcDaddy]

I am hoping someone can help me understand this function from the provably fair conversions page:

More specifically, I am trying to understand what 'value' is derived from/how it is calculated/what affect it has on the result.

I see in my archives that it can repeat across close-proximity nonces and possibly based on betsize? Again, this is where I am looking for help. 
Are these even the same 'value' be referenced?

Thanks in advance.

@dupeddonkrequesting your expertise

[Jooshee]

Don’t think of gambling as fair otherwise you’re in for a treat. 
its about skill and luck

[PJAlina]

There’s no such thing as provable fair in gambling my dude. Just luck and more more more…. money to sacrifice.. ✌️😅

[ltcDaddy]

 

35 minutes ago, Jooshee said:

Don’t think of gambling as fair otherwise you’re in for a treat. 
its about skill and luck

 

23 minutes ago, PJAlina said:

There’s no such thing as provable fair in gambling my dude. Just luck and more more more…. money to sacrifice.. ✌️😅

Thank you both for blessing this thread with your intellectual prowess.
This is a math/calculation question, not a debate on the fairness of gambling.

[dupeddonk]

The byteGenerator function (which is called when const rng is declared inside of generateFloats) is what returns the sha256 hash that we use to determine result.

So, byteGenerator will always return 256 bits based on player/server/nonce and cursor.  In this case it's hexadecimal.

The generateFloats goes through the 256 bits, 4 bytes at a time, and turns them into floats (floating point numbers).

 

One thing that stumped me for a while is the fact that stake treats every calculation as if it needs a cursor, even if it doens't.  

So for games like dice or limbo, if you just calculate the hmac of sha256(serverseed, playerseed:nonce) it will never match.  You need to add on an extra 0 as the cursor, so hmac_Sha256(server, player:nonce:0) .

 

Anyone, feel free to tell me what doesn't make sense and I'll go into more detail. happy to talk about this stuff.  (Kinda busy this weekend but will get to it eventually)

 

 

 

[ltcDaddy]

1 hour ago, dupeddonk said:

The byteGenerator function (which is called when const rng is declared inside of generateFloats) is what returns the sha256 hash that we use to determine result.

So, byteGenerator will always return 256 bits based on player/server/nonce and cursor.  In this case it's hexadecimal.

The generateFloats goes through the 256 bits, 4 bytes at a time, and turns them into floats (floating point numbers).

 

One thing that stumped me for a while is the fact that stake treats every calculation as if it needs a cursor, even if it doens't.  

So for games like dice or limbo, if you just calculate the hmac of sha256(serverseed, playerseed:nonce) it will never match.  You need to add on an extra 0 as the cursor, so hmac_Sha256(server, player:nonce:0) .

 

Anyone, feel free to tell me what doesn't make sense and I'll go into more detail. happy to talk about this stuff.  (Kinda busy this weekend but will get to it eventually)

 

 

 

So the 'value' in the archive is actually the dollar value of the bet I think. That answers part of my confusion.

In the function, however, is this basically saying each 'value' is a set of 4 bytes, which is then returned as partialResult at the bottom?
I made the mistake of thinking they were the same 'value' when really they are completely unrelated.

Thanks for your input.

[dupeddonk]

On 8/14/2021 at 2:04 PM, ltcDaddy said:

So the 'value' in the archive is actually the dollar value of the bet I think.

This function doesn't know the amount bet (or any other option the player makes like risk level, lines played, tiles chosen, etc.).  

In order to determine the outcome we only need the client seed, server seed and nonce as well as which game we're playing so we know how many rounds to generate and what exactly we should do with the hashed value of the seeds and nonce.

Without getting too technical value is used in the example you highlighted as a way to literally call the current value of 4 specific bytes the while loop is looking at the first time, and the next two times as a required argument for the reduce() function, which basically just iterates over each values of an array (in this case the array is called bytesChunk )and then does something to it.

In the limbo bets program I wrote, you may have noticed that there's nothing that really looks like this in the code, that's because for Limbo, we only need 16 bytes of data to get a result, so I just wrote a function that only looks at the first 4 characters (16 bytes) to keep things simple.

So quick sanity check:

the byteGenerator() function always returns a hexadecimal 256 byte string, which means 64 characters consisting of 0-9 and a-f.  (Doesn't matter how long the value is that's being hashed, 1 character or 1 billion characters will both return a unique 64 hexadecimal character hash.)

So when given the seeds and nonce, byteGenerator() returns a string that looks like this:

796a3babd02f826628e154ae19650461dc444b49f90d514cc005fd7fe0469eed

This actually happens from within the generateFloats() function:

So now, rng is a variable that's pointing to => 796a3babd02f826628e154ae19650461dc444b49f90d514cc005fd7fe0469eed

If we're calculating Limbo or Dice, we just take the first 4 characters and forget about the rest.  Otherwise, we need to break up those 64 characters into 4 character chunks.  And if we run out of characters before we have enough we increase the cursor by 1 and recalculate a whole new hash, (cursor is basically just another nonce - the nonce increases between each bet, the cursor increases within each bet and is reset to 0 with each new bet)

 

Hope that clears some stuff up.