Pages:
Author

Topic: FIRST Peer-2-Peer betting website. NO HOUSE & NO DEALER 1$ UNLIMITED GAINS (Read 1785 times)

legendary
Activity: 1463
Merit: 1886
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.
legendary
Activity: 1512
Merit: 1218
Change is in your hands
Happy to help... Feel free to get in touch with me on PM. I don't use skype anymore.
copper member
Activity: 56
Merit: 0
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.
legendary
Activity: 1512
Merit: 1218
Change is in your hands
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...
copper member
Activity: 56
Merit: 0
Betroom's Ice Breaker Event


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

click>>>JOIN NOW<<
copper member
Activity: 56
Merit: 0
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  Grin

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.
legendary
Activity: 1463
Merit: 1886
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  Grin
copper member
Activity: 56
Merit: 0
So yes, please present me with a viable solution that will allow the server to send a random number sequentially to the players that jump in real time while the server does not know the end value in advance. Thank you.

It's your job to find a solution. 

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.
legendary
Activity: 2660
Merit: 2064
Join the world-leading crypto sportsbook NOW!
So yes, please present me with a viable solution that will allow the server to send a random number sequentially to the players that jump in real time while the server does not know the end value in advance. Thank you.

It's your job to find a solution. 
copper member
Activity: 56
Merit: 0
Would it be possible to do this without a server seed? (assuming we have multiple client seeds)

Yeah, there's no need for a server-seed if it's just a peer-vs-peer gambling game.

This won t solve the problem neither.

Hmm. I could explain to you a solution to make it work -- but before I do that -- do you see the problem with the current way you're doing it? Do you see why it's not actually provably fair -- and offers players no additional guarantees?

Hmm. I could explain to you a solution to make it work -- but before I do that -- do you see the problem with the current way you're doing it? Do you see why it's not actually provably fair -- and offers players no additional guarantees?

Since the server knows the result before, then it s clear that neither mine nor the solution presented by you above are NOT actual solutions. So yes, please present me with a viable solution that will allow the server to send a random number sequentially to the players that jump in real time while the server does not know the end value in advance. Thank you.
legendary
Activity: 1463
Merit: 1886
Would it be possible to do this without a server seed? (assuming we have multiple client seeds)

Yeah, there's no need for a server-seed if it's just a peer-vs-peer gambling game.

This won t solve the problem neither.

Hmm. I could explain to you a solution to make it work -- but before I do that -- do you see the problem with the current way you're doing it? Do you see why it's not actually provably fair -- and offers players no additional guarantees?
copper member
Activity: 56
Merit: 0
Betroom is officially Provably Fair

I'm always interested in provably fair systems, but I don't see how this is remotely is. The first problem is there's a real lack of information/example (as in a concrete example specific to the game), which makes verification more or less impossible even if it was provably fair. But besides that, I don't even see how the method you are using even attempts to solve the problem.

So as I understand it, at a high-level you're trying to do something like:

* Server generates a server-seed
* Server gives clients a hash of the server-seed (to prove it doesn't change)
* Each clients provide the server a client-seed after they've seen the server-seed hash

And then the game result is computed as a function of (ServerSeed, ClientSeeds).

---

If I'm understanding right, that doesn't solve anything at all -- because if any client was controlled by the server, it could pick a client-seed that will make it win.

--

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.


P.S. I'll PM you a security problem i (think i) found

P.P.S. How come your site says there's 470 people online? Surely that can't be real?



P.P.S. How come your site says there's 470 people online? Surely that can't be real?

We are running marketing large campaigns on many websites and get traffic all the time. "Online" means visitors, not users that are signed in.

P.S. I'll PM you a security problem i (think i) found

Solved that just now, thank you so much!

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.

This won t solve the problem neither. As i explained to my arch-enemy TwitchySeal, with this game in particular, since it s a reactive game, the server must know the result in advance, so this won t work either. Let me explain how the game is made so that you know the actual problem and then you might help me find a solution to this - i m referring to the Rocket Crash game.

1. Clients buy tickets to join the game.
2. Once there are at least 10 players that bought tickets for that event, the countdown starts.
3. In the mean time clients can choose the client seed and send it to the server.
4. Server computes server seed + client seed + nonce into one piece of string and the function generates the random number when the timer strikes zero.
5. This number is sent SEQUENTIALLY (unit by unit every tenth of a second) to clients because if the final value is sent, then with a small hack clients will know what the actual crash value will be.
6. Game starts and clients jump off the rocket IN REAL TIME.

The problem comes at "5" because the server MUST know the crash value BEFORE game start in order to divide it and send it unit by unit to the players. If players would not jump in real time, then yes, what you are saying is correct and could be implemented so that a result would not be known by any party before the actual event took place. In this particular case, the server does not
need to control the client seed since it "knows" the actual crash value in advance.
So, with this particular game, if you have a solution to it, please let me know and if it s real, i ll implement it.
legendary
Activity: 2660
Merit: 2064
Join the world-leading crypto sportsbook NOW!
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)

legendary
Activity: 1463
Merit: 1886
Betroom is officially Provably Fair

I'm always interested in provably fair systems, but I don't see how this is remotely is. The first problem is there's a real lack of information/example (as in a concrete example specific to the game), which makes verification more or less impossible even if it was provably fair. But besides that, I don't even see how the method you are using even attempts to solve the problem.

So as I understand it, at a high-level you're trying to do something like:

* Server generates a server-seed
* Server gives clients a hash of the server-seed (to prove it doesn't change)
* Each clients provide the server a client-seed after they've seen the server-seed hash

And then the game result is computed as a function of (ServerSeed, ClientSeeds).

---

If I'm understanding right, that doesn't solve anything at all -- because if any client was controlled by the server, it could pick a client-seed that will make it win.

--

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.


P.S. I'll PM you a security problem i (think i) found

P.P.S. How come your site says there's 470 people online? Surely that can't be real?
copper member
Activity: 56
Merit: 0
I got my loyal sidekick in you, it cannot get better. Check it out of course, i also posted the implementation, here it is: https://github.com/alexcambose/provably-fair-example
The link takes you to github where the code resides. I m not the author of the code, Alex Cambose is, but i used it for myself too.
To make things even smoother for you, i will show you how it works - in pictures (chart below).

legendary
Activity: 2660
Merit: 2064
Join the world-leading crypto sportsbook NOW!
Betroom is officially Provably Fair



Have you wondered if the outcome of a bet is changed AFTER you placed the bet? Besides being a "No Dealer & No House Policy" platform, Betroom comes in support of its players with an additional method of proving that the TRUTH is the ONLY option on the table.

For a detailed explanation on how the verification system works and why it's important, check out our Knowledge Base page.

The method is now available for the Rocket Crash game and will soon be available for the rest of the games.

Let's change the betting industry for the better. Only TOGETHER we can achieve this. To support us and our revolution, YOUR revolution, LOG IN or CREATE AN ACCOUNT FIRST and PLAY !

If you feel we can do something to make this a better experience for you, don t hesitate, drop us an email at [email protected] and we'll take notice of your feedback.

Hey, great decision.

I won't have time to verify it's actually provably fair for a few days, but I'm impressed you've taken steps to make the attempt nonetheless.

As I said before, be prepared to be scrutinized.
copper member
Activity: 56
Merit: 0
Betroom is officially Provably Fair



Have you wondered if the outcome of a bet is changed AFTER you placed the bet? Besides being a "No Dealer & No House Policy" platform, Betroom comes in support of its players with an additional method of proving that the TRUTH is the ONLY option on the table.

For a detailed explanation on how the verification system works and why it's important, check out our Knowledge Base page.

The method is now available for the Rocket Crash game and will soon be available for the rest of the games.

Let's change the betting industry for the better. Only TOGETHER we can achieve this. To support us and our revolution, YOUR revolution, LOG IN or CREATE AN ACCOUNT FIRST and PLAY !

If you feel we can do something to make this a better experience for you, don t hesitate, drop us an email at [email protected] and we'll take notice of your feedback.
copper member
Activity: 56
Merit: 0
Sorry for the downtime, had some issues with the servers, now we re back live. New posts features and posts coming up today, stay tuned!
hero member
Activity: 2296
Merit: 953
Temporary forum vacation
If you're taking 3% of every bet, your average players EV will be 97%.  If some players find a way increase their EV, other players EV will drop below 97%, just like any other p.

This was what I thought every time I see a PVP game, it attracts me until I see what the commission is. I think at least you have to change the marketing. It is fine to say no house,,, but not fine to say no house edge when you do take a commission. 3% commission is a lot compared to 1% house edge, in my opinion.

You have to add a prize pool just to make it neutral EV Smiley
copper member
Activity: 56
Merit: 0
Which are those resources you pointed out to me? There s not a single reference.

Seriously?

Check out https://cryptogambling.org/  or go visit their thread: https://bitcointalksearch.org/topic/crypto-gambling-foundation-fair-gambling-for-all-2178857, ask them what they think about relying on the built in javascript
Code:
math.random()
instead of a provably fair algorithm.

Do some googling.  Research your competition, figure out why some have been around for years and maintain a great reputations with a solid player base and others are ghost towns (or already folded) and have a bad reputation. 

Find the people that developed the successful sites and ask them for advice, many of them would be very willing to help you out - but only if you stop being such an asshole.



I started liking you that much, i might even start a signature campaign with you alone.
Pages:
Jump to: