Chartbet bug bounty?

[cryptobird71]

Ive found a bug I would like to report to the forums here for a bug bounty  Pretty important bug too.  

 

Issue:  Cashed Out multiplier reads a higher number than the number it crashes at. i.e.  Cashed out @ 1.38x and system says crashed at 1.37x.  Has happened once on mobile device of which i have attached the picture below and then also on my laptop.  The second time it happened on my laptop i cashed out at 1.58x and the system said it crashed at 1.57x

Problem: Can lead to a further exploitation or possibly finding of new vulnerabilities within the website.  Possibly something with the math while the algorithms are solving the hash?  Could be something just as simple as server lag as well, but I do not think so as it has happened more than once. Its happened 2 times within 3 days.

Let me know what you devs think and what i can do to help as well possibly

Easiest way to reach me would be through telegram

telegram: @cryphaZon

Thanks

CryptoGavin

[Snike]

Nice find, but how is this "exploitable"? What should one get through this? 0.01x more profit?

[Shaniqua]

15 hours ago, Snike said:

Nice find, but how is this "exploitable"? What should one get through this? 0.01x more profit?

that is the golden question aint it...
if you cant replicate it on demand, i dont think it would be considered exploitable 
but then again... who knows... only the devs i guess.. dan can weigh in too Support staff as well

[cryptobird71]

WARNING NOVEL AHEAD!  NOVEL AHEAD!

Haha sorry for the length but Lost track of time writing this, and also tried squeezing it down to the smaller version while including researching.  Started researching around midnight and then started putting thoughts down on paper around 2:15am.  It's now 5:30m lol  and this little bit was the last part I wrote haha.

NOTE**  Just for the record, The event i described above has happened a 3rd time in 4 days now; First time was 1.38xx cash out with a crash at 1.37x, Second time was 1.58x cash out with a crash at 1.57x, Third time was 1.78x cash out with a crash at 1.77x
So that is pretty consistent for something that is supposed to be mathematically verifiable.  

To answer you all as well, I will address your questions on re-creation of the issue, vulnerability danger,  through my concerns and questions.  Plus Ill also give a real life example of how something that pertains to a similar situation too

First off.  It's true, being able to replicate any situation again you must have very key components and information. Math and science can make recreating those situations difficult  and almost impossible at times due to not having the same environment, materials, and workspace to back test and evaluate the data hypothesize and experiment  With Math and Science we all know it has to needs to be and must be logical, correct and be in cconsensus must be achieved to allow it to work properly.
Three questions I thought about so far before a hella lot of research last night were:

1.  Despite being created, calculated and verifiable by its mathematical algorithm through  functions and permutations that by definition MUST achieve consensus; Why does a "verifiable Randomly Generated Number" that has made not achieving consensus possible with the Cash out and Crash point? 

2. Why and How has it created two separate randomly generated numbers, a Cash out number and  a Crash number and still sees two different numbers as consensus (only thing i can think of is a miscalculation or typo or bug in the algorithms calculations or function setup that is causing the solutions to slightly differ one another)

3.   Are the server seeds encrypted or decrypted  at all times?  Could this bug be exploitable when the Seed/Nonce have the calculation error?  Possibly create and ability to customize your client seed in such a way to where you can control the numbers generated  Could someone decode the Server Seed in order to be able to calculate the Randomly Generated Number before the bet so t

Definitely do not have an issue that I am getting cashed out 0.01X higher. 

Dont mind bonuses  haha
 
 

In crypto and with algorithmic functions and encryptions to be effective within the P2P network, and achieve general consensus, Otherwise, its your loss on consensus and 

A vulnerability I can see right now is the discrepancy between one verifiable Randomly Generated Number, and having two Randomly Generated numbers 0.01X off each other.
Where an exploit comes in is a combination of using decrypted Server and Client Seeds, calculating the Randomly Generated number from the Hash to know the exact number that will be played.  After you strategize placing your bet accordingly based on the number calculated.  Since the better would have both Server and Client seed Decrypted already they would also be able to verify this transaction with me at work.

 Remember what Thomas Edison said when he invested the light bulb " Well, I found thousands of ways that a light bulb would not work and only found one way it would work" Science and Mathematics run in the same boat when the engineering of computer code.
 

In Prime Dice's hack, a unknown a hacker exploiting the RNG protocols, gaining access there were multiple active and inactive decrypted server seeds that were traced back to and being used by90the malicious individual and their multiple gambling accounts.  One that knows cyber security/penetration testing plus has the will to figure it out eventually will.  Just would rather not see a website I appreciate taken for a ride anytime in the futureSo for PrimeDice,   

just know that if something  like this would be a big issue in provably fair gaming.

Here is a quote from the article Prime Dice Released so other sites and people can learn from their mistake and how HufflePuff exploited prime dice with similar pieces of information.
"main developer detected the exploit after we found a handful of accounts sharing the same server seed.

To understand how Hufflepuff beat our system, one must understand how our provably fair system (RNG) works. A user is shown an encrypted random value (the server seed) before they bet and they must also submit their own random value (the client seed). These two random values are combined and used to determine win or lose. The random encrypted random value used for the bet then is shown to the user after the bet so that they can be guaranteed that their bet is not rigged. You can find the detailed and in-depth explanations of provably fair here:

https://primedice.com/verify and http://dicesites.com/provably-fair

Part of the functionality of our site is that we have to give out decrypted server seeds (to assure users no bet manipulation has occurred) and put a new random seed in place, essentially trashing the old revealed seed. Hufflepuff found a way to “confuse” our server, and made it give out a decrypted server seed that was also an active seed. This was done by sending it more requests than it could handle in a small time period, think hundreds of requests in under a second. The result of this is that he knew all the information required to corroborate the outcomes of his bets. He knew whether if he would win or lose, and could wager accordingly.

We figured this out after frantically checking our servers after a eureka moment. We suspected something could have been going on and eventually realized the possibility of a timing attack described above. Our database had seeds that were both inactive and in use at the same time all connected to Hufflepuff. Along these “Schrödinger” seeds existed many seemingly unused seeds connected to the same accounts, indicative of the rapid fire of requests needed to obtain these."

 

[williamshennie9]

I honestly don't see this as a bug, and if it is, like Snike said, you'll only get 0.01x more profit. But let's see what @Dan has to say. Maybe it is more serious than I am giving it credit for.

[Dan]

Thanks for reporting this visual issue. Sadly its not exploitable, the wya you can check is via the API doing a bet lookup on your betid via: https://api.stake.com/graphql

The issue is the front end is just rounding down instead of rounding up. Locking this topic.