[SERIOUS] How would you guys feel about a provably fair seed api?

[CrazyCraig]

Im in the process of developing a provably fair seed api. Basically, the api will provide the requester an X number of randomly generated, never used hashes. Once the client seed is set, the server will send back the unhashed seed. Obviously, I had to simplify the process down a bit for general understanding, but in reality the unhashed keys are stored in hmac with the client defining the salt. This is just one level of planned security.

Process:
Request X Hashes (1-5 Group)
Set Client Seed
Return Seed
Client Generates roll.

I do not want to go further in depth with my idea just yet for the risk of competition, but my thoughts are this could possibly turn into a trusted service as it adds several key features

- Reduces risk of new sites that use api.
- Keys / Hashes stored off server.
- Easy user lookup to verify integrity onsite
- Larger sites, off server load reduction.
- Random Unique keys, never reused.

[LiQuidx]

Im in the process of developing a provably fair seed api. Basically, the api will provide the requester an X number of randomly generated, never used hashes. Once the client seed is set, the server will send back the unhashed seed. Obviously, I had to simplify the process down a bit for general understanding, but in reality the unhashed keys are stored in hmac with the client defining the salt. This is just one level of planned security.

Process:
Request X Hashes (1-5 Group)
Set Client Seed
Return Seed
Client Generates roll.

I do not want to go further in depth with my idea just yet for the risk of competition, but my thoughts are this could possibly turn into a trusted service as it adds several key features

- Reduces risk of new sites that use api.
- Keys / Hashes stored off server.
- Easy user lookup to verify integrity onsite
- Larger sites, off server load reduction.
- Random Unique keys, never reused.

Why would anyone trust a 3rd party for generating hashes that will be used for betting?

[CrazyCraig]

Completely understand the concern. That's what I'm trying to address

[LiQuidx]

Completely understand the concern. That's what I'm trying to address

I think there's no easy way around it (if any), therefore you will have hard time getting people to use your service. Good luck either way.

[Joel_Jantsen]

Why would anyone trust a 3rd party for generating hashes that will be used for betting?

►Open source ,transparency ?
►Trusted by the community ?
►Standardized API.
►Ease of use.
►Not easily Manipulative.

and I could go on...project has a great potential like MoneyPot,its third party too but trusted by the community right ?I totally support the idea.

[LiQuidx]

Why would anyone trust a 3rd party for generating hashes that will be used for betting?

►Open source ,transparency ?
►Trusted by the community ?
►Standardized API.
►Ease of use.
►Not easily Manipulative.

and I could go on...project has a great potential like MoneyPot,its third party too but trusted by the community right ?I totally support the idea.

I mean let's say i'm casino X. And I want to use this service. CrazyCraig knows that he has given me xyz seeds. What stops him (or anyone who has access there) to come and clean casino X?
That's what I meant... I'm not saying that this is his intention but it's obviously a security concern.

[CrazyCraig]

The issue is transparency. My service wouldn't store the seed in plain text. Client application would define a salt. Ideally, this may cause concern as some could claim I'm storing the salts. But say, this is a registered business, legally insured etc. would that change opinions? Ideally, this seed would used in addition to the client server seed.

[Joel_Jantsen]

The issue is transparency. My service wouldn't store the seed in plain text. Client application would define a salt. Ideally, this may cause concern as some could claim I'm storing the salts. But say, this is a registered business, legally insured etc. would that change opinions? Ideally, this seed would used in addition to the client server seed.

Nope.By provably fair means,anyone should be able to verify the seeds and must be transparent.Otherwise,how are you expecting people to trust your service ?You already have to put in lot of efforts to convince gambling sites to use your service regardless of the legal confirmations.

[CrazyCraig]

My thoughts that after the seed was used, meaning the client seed was defined, the seed would unlock and be verifiable on the site itself.

Obviously I need to investigate more into the application interface and security level. Need to provide transparency against hackers and for clients.

[NLNico]

The site owners would need to fully trust you, which seems risky. You could indeed use the seed and the clientseed to cheat the casino. For MP apps, this isn't an issue since the MP apps are not risking their own BR. (edit: misunderstood, site owner still calculates) Also you seem to imply a performance boost, but putting something like this in between each bet must be pretty bad for performance.

However, I once had a somewhat similar idea for a "seed server" - but more as "Audit server" that doesn't calculate the result themselves. See this topic from '14: https://bitcointalk.org/index.php?topic=774458.all

Here is a diagram to make it more easy to understand:






If my idea has some (fatal) flaws, let me know :p Also again, I am pretty sure it's all not worth the effort (especially performance-wise.) For player, provably fair works pretty okay already if they take the time to verify their rolls. And for investors (and partly for players too), they can still lose all their money if site owner simply steals it all. So myeh.

[CrazyCraig]

You seem to have a lockdown on what I was trying to accomplish as well. Like your method, my service would not handle calculations. Just seed generation / validation.

[amacar2]

Moneypot is out there providing almost similar service for betting but we can't use our own bankroll to run the casino and get all those loss as profit. So if you could lunch open source script and start building good trust towards your service which should be secure and you can't manipulate the result easily. Simply launching an open source script that can be easily implemented with any script via api call would be great way for you to earn some reputaion, don't know how you will try to pull some compensation for your all good effort, may be you could get few donation if this works.

[CrazyCraig]

Moneypot is out there providing almost similar service for betting but we can't use our own bankroll to run the casino and get all those loss as profit. So if you could lunch open source script and start building good trust towards your service which should be secure and you can't manipulate the result easily. Simply launching an open source script that can be easily implemented with any script via api call would be great way for you to earn some reputaion, don't know how you will try to pull some compensation for your all good effort, may be you could get few donation if this works.

I have a montization plan. Billing would occur for x number of requests after a set threshold.

[RocketSingh]

Im in the process of developing a provably fair seed api.

Why would someone use your API while they can get absolutely random seeds from bitcoin blockchain itself? In fact, I recently saw a game, www.bitcoinbetting.website, is exactly doing that.

[CrazyCraig]

Im in the process of developing a provably fair seed api.

Why would someone use your API while they can get absolutely random seeds from bitcoin blockchain itself? In fact, I recently saw a game, www.bitcoinbetting.website, is exactly doing that.

The thought process behind it would geared towards site users. It would offer insurance that site operators are not predicting seed outcomes based on client seed before roll generation. Would also operate as a centralized hub for validation

[LiQuidx]

Im in the process of developing a provably fair seed api.

Why would someone use your API while they can get absolutely random seeds from bitcoin blockchain itself? In fact, I recently saw a game, www.bitcoinbetting.website, is exactly doing that.

The thought process behind it would geared towards site users. It would offer insurance that site operators are not predicting seed outcomes based on client seed before roll generation. Would also operate as a centralized hub for validation

Since the client provides what you referring as salt, it can still manipulate the outcome. Am I missing something? Also another security concern is that the service would become a single point of failure. Meaning that if it is compromised then a number of sites that will be using your service are immediately exploitable.

[MillionsBTCdev]

In my honest opinion, this is a good idea to profit from  a few lines of codes, that is if casino sites do trust you with it. And like the posts above, performance wise, its not really faster than what casinos have now, or might even be slower. I get the part that if a player knows that the casino gets the seed from a 3rd party, they could not cheat, removing the need for trust on the casino, but then the trusting part goes to you. Players/Casinos should be able to trust you that you are 1. not colluding with the casino, or 2. not colluding with the player.

There are alot of factors to take into consideration, like bet algorithm, is the casino using nonces? or are they a 1 bet:1 seed pair, does the casino accept Hex encoded seeds, or just numerals, the length of the seeds etc. There is no 'universal' format for the server seed, so if ever a casino takes your service, one of you would have to adjust.

Another thing to take into consideration is the technical cost of the backend storage. 1-2M bets per site per day, will eat away your storage if you store each seed.

Also your reason about, casinos predicting the seed based on your client seed. This is almost non-existent specially to casinos that uses nonces. A single server seed is generated and shown to the user even before he could set a client seed. So once the user changes seed pairs, the next server seed hash will already by shown. The user will only have to change client seed whenever he changes a seed pair.

Even if the idea is great IMO, its not worth it. Maybe if you could think of something more to add other than just seed generation, there could be potential.


-uni