FIRST Peer-2-Peer betting website. NO HOUSE & NO DEALER 1$ UNLIMITED GAINS

[RHavar]

Oh, i see now. So you brought in your companion. So let me get it, you guys don t really present solutions, do you? I mean, you could go off bragging all day why there hasn t been a cancer cure yet or why the earth spins instead of staying still, but when it comes to solving real world problems, you just disappear into the night. As far as this goes, i can implement your buddy s solution up there but again, it won t solve the problem since the server needs to know the crash value in advance and since the game is played after the value of the server is being generated. If you wanna be of any help, give me a solution. If not, let it be.

You have a toxic attitude. Frankly, it's your site and you're the one advertising "provably fair" -- so clearly the onus is on you to do the work and find and implement a solution to be provably fair (or stop advertising it as such).


I was planning on explaining a semi-workable way to do your real-time game in an actual provably fair way, but before I did so, I wanted to make sure you understand the flaws in your system -- as it's a waste of my time in trying to show someone to fix something that they don't understand is broken. But I have a feeling I could be spending time on more productive things  

[1714707880]

1714707880

[1714707880]

1714707880

[1714707880]

1714707880

[betroom.eu]

Oh, i see now. So you brought in your companion. So let me get it, you guys don t really present solutions, do you? I mean, you could go off bragging all day why there hasn t been a cancer cure yet or why the earth spins instead of staying still, but when it comes to solving real world problems, you just disappear into the night. As far as this goes, i can implement your buddy s solution up there but again, it won t solve the problem since the server needs to know the crash value in advance and since the game is played after the value of the server is being generated. If you wanna be of any help, give me a solution. If not, let it be.

You have a toxic attitude. Frankly, it's your site and you're the one advertising "provably fair" -- so clearly the onus is on you to do the work and find and implement a solution to be provably fair (or stop advertising it as such).


I was planning on explaining a semi-workable way to do your real-time game in an actual provably fair way, but before I did so, I wanted to make sure you understand the flaws in your system -- as it's a waste of my time in trying to show someone to fix something that they don't understand is broken. But I have a feeling I could be spending time on more productive things  

You have a toxic attitude.

No i don t. You guys come in here banging on the door and then leave out the window. What i mean by this is that everyone talks about problems but i have seen no real solutions. If you wanna be of any help except bashing left and right, get in and help, otherwise don t waste my time and the people reading this thread.

[betroom.eu]

Betroom's Ice Breaker Event

FREE tickets for tomorrow's Ice Breaker Event!!!

click>>>JOIN NOW<<<click

[Thekool1s]

The only way you're (sanely) going to get a game like this to be provably fair, is have each client have a secret -- send a hash of the secret to the server (which broadcasts to all other clients). Then when the client has seen the hash of all other clients seeds, reveals it's own seed. Then the game result is computed based on all the client seeds.

Would it be possible to do this without a server seed? (assuming we have multiple client seeds)

So a little backstory, I ran a lottery of sorts a while ago, it was basically PVP or peer 2 peer. 10 people would participate in a round and the prize of the pool was distributed to the top 3 players who rolled the highest number between 1-100... We stumbled upon this very issue. The server generating the seed will always have an edge over the other clients. The way we solved this issue was by selecting a server seed which was based on future bitcoin block's hash, something basically we had no control over. So when the client bought a ticket their client seed was stored in the public ledger on the website and once the 10 tickets were bought, a round hash was generated and mailed to all the participants, basically ensuring that none of the client seeds are changed afterwards. After that, the game waited for a new bitcoin block to be generated and its hash was used as a server seed to generate the rolled numbers. That's how we made it provable fair by simply taking away the edge from everyone.

Rolled number = Future Bitcoin Block's hash(acts as server seed) + Client seed + Random Nonce of each round.

Unfortunately, the game didn't get much traction and i had to shut it down...

[betroom.eu]

The only way you're (sanely) going to get a game like this to be provably fair, is have each client have a secret -- send a hash of the secret to the server (which broadcasts to all other clients). Then when the client has seen the hash of all other clients seeds, reveals it's own seed. Then the game result is computed based on all the client seeds.

Would it be possible to do this without a server seed? (assuming we have multiple client seeds)

So a little backstory, I ran a lottery of sorts a while ago, it was basically PVP or peer 2 peer. 10 people would participate in a round and the prize of the pool was distributed to the top 3 players who rolled the highest number between 1-100... We stumbled upon this very issue. The server generating the seed will always have an edge over the other clients. The way we solved this issue was by selecting a server seed which was based on future bitcoin block's hash, something basically we had no control over. So when the client bought a ticket their client seed was stored in the public ledger on the website and once the 10 tickets were bought, a round hash was generated and mailed to all the participants, basically ensuring that none of the client seeds are changed afterwards. After that, the game waited for a new bitcoin block to be generated and its hash was used as a server seed to generate the rolled numbers. That's how we made it provable fair by simply taking away the edge from everyone.

Rolled number = Future Bitcoin Block's hash(acts as server seed) + Client seed + Random Nonce of each round.

Unfortunately, the game didn't get much traction and i had to shut it down...

This is some GREAT insight. Can we chat a bit about it? Do you have a skype id or something? I want to learn more if you are willing to share. Thank you so much.

[Thekool1s]

Happy to help... Feel free to get in touch with me on PM. I don't use skype anymore.

[RHavar]

So a little backstory, I ran a lottery of sorts a while ago, it was basically PVP or peer 2 peer. 10 people would participate in a round and the prize of the pool was distributed to the top 3 players who rolled the highest number between 1-100... We stumbled upon this very issue. The server generating the seed will always have an edge over the other clients. The way we solved this issue was by selecting a server seed which was based on future bitcoin block's hash, something basically we had no control over. So when the client bought a ticket their client seed was stored in the public ledger on the website and once the 10 tickets were bought, a round hash was generated and mailed to all the participants, basically ensuring that none of the client seeds are changed afterwards. After that, the game waited for a new bitcoin block to be generated and its hash was used as a server seed to generate the rolled numbers. That's how we made it provable fair by simply taking away the edge from everyone.

Rolled number = Future Bitcoin Block's hash(acts as server seed) + Client seed + Random Nonce of each round.

Unfortunately, the game didn't get much traction and i had to shut it down...

That's pretty much how I did it for pevpot too, but with a little twist to make it pretty robust against miner's interference:

https://web.archive.org/web/20151213003346/https://www.pevpot.com/provably-fair


Sadly it also suffered the same fate.