Re: ⭐ TronFun | Roulette&Duels | Provably Fair/Social Games | Fast Dep/With BTC-TRX
Congratulations on the launch. Unfortunately your provably fair system isn't actually provably fair. In fact, it's not even provably pre-determined 
Firstly, never use md5, it's been fully obsoleted for almost 15 years. You're already using sha256, so just stick to that. No need to mix in anything different. But the way you use it is very strange, you md5 the ROUND_CREATED ... for no purpose. And then don't md5 the ROUND_ENDED. You could actually just remove md5 with no functional difference.
But your fatal flaw is you have control of three variables SECRET, ROUND_CREATED and ROUND_ENDED which are timestamps. There's no way to validate that these values are picked fairly. The ROUND_ENDED is particularly insidious, because it would allow you to trivially cheat (i.e. make the round end 1 second later/earlier to prevent someone winning big).
If you are interested, I'm happy to help you integrate a best-in-class provably fair system and give you some demo code. I run https://provablyhonest.com/ and your roulette use case is well supported. Basically you'd use a hash-chain exactly like this: https://github.com/provablyhonest/vx-demo/blob/master/crash.ts#L75 and I'd make a custom roulette game type for you (which the outcome could be simply `vx_signature % 15` ). Anyway, if you're interested I'm happy to help. (And besides creating a robust provably fair system, my scheme would also help provide additional security guarantees)
Firstly, never use md5, it's been fully obsoleted for almost 15 years. You're already using sha256, so just stick to that. No need to mix in anything different. But the way you use it is very strange, you md5 the ROUND_CREATED ... for no purpose. And then don't md5 the ROUND_ENDED. You could actually just remove md5 with no functional difference.
But your fatal flaw is you have control of three variables SECRET, ROUND_CREATED and ROUND_ENDED which are timestamps. There's no way to validate that these values are picked fairly. The ROUND_ENDED is particularly insidious, because it would allow you to trivially cheat (i.e. make the round end 1 second later/earlier to prevent someone winning big).
If you are interested, I'm happy to help you integrate a best-in-class provably fair system and give you some demo code. I run https://provablyhonest.com/ and your roulette use case is well supported. Basically you'd use a hash-chain exactly like this: https://github.com/provablyhonest/vx-demo/blob/master/crash.ts#L75 and I'd make a custom roulette game type for you (which the outcome could be simply `vx_signature % 15` ). Anyway, if you're interested I'm happy to help. (And besides creating a robust provably fair system, my scheme would also help provide additional security guarantees)