Jump to content

How to create casino custom strategies (API similar solution)


Featured Comment

are you sure it is possible to change separately client and server seeds?

the only frontend method i found is "mutation RotateSeedPair" that accepts new client seed and in response gives new pair

Quote

mutation RotateSeedPair($seed: String!) {
  rotateSeedPair(seed: $seed) {
    clientSeed {
      user {
        id
        activeClientSeed {
          id
          seed
          __typename
        }
        activeServerSeed {
          id
          nonce
          seedHash
          nextSeedHash
          __typename
        }
        __typename
      }
      __typename
    }
    __typename
  }
}
 

with variable

Quote

{
    "seed": "stakeisbestcasino"
}

 

Link to post
Share on other sites
4 minutes ago, forzaXD said:

are you sure it is possible to change separately client and server seeds?

the only frontend method i found is "mutation RotateSeedPair" that accepts new client seed and in response gives new pair

with variable

 

Yes, I'm absolutely sure, since I was done that until previous week... before these changes/restrictions on APIs.

The mutation to rotate server seeds (both client and server), I have thanks... and it can be get from frontend of course.

I want only add... WTF!!! now also primedice is applying the same restrictions on queries!!!... now I have to adjust my presetted file (with functions of all commands) also for primedice... but wtf!!!

Link to post
Share on other sites
1 minute ago, Dan said:

I am so proud of you @ivand2128

Thanks @Dan ... but what means? :)

I don't understood.

Since you're here... could you post me the query to change only client seed please? so I have newly all commands like before. I'd really appreciate.

P.S.

Until yesterday (+/-) primedice was free of these restrictions... has been you to apply also there? :)

Link to post
Share on other sites
  • Forum Admin
3 minutes ago, ivand2128 said:

Thanks @Dan ... but what means? :)

I don't understood.

Since you're here... could you post me the query to change only client seed please? so I have newly all commands like before. I'd really appreciate.

P.S.

Until yesterday (+/-) primedice was free of these restrictions... has been you to apply also there? :)

Yes it is now applied on primedice, and the reason you cant change only the client seed is because it was removed due to not being provably fair.

Link to post
Share on other sites
9 minutes ago, Dan said:

Yes it is now applied on primedice, and the reason you cant change only the client seed is because it was removed due to not being provably fair.

Why not being provably fair ?

When I was changing only client seed, the nonce was NOT resetted to 0, it was continuing increase from original starting of server seed... and, to verify the bets, it was only need to sign the nonce where client seed was changed.

So, how could be it was not provably fair?

(If also nonce was setted to 0, on changing only client, then I agreed it's not provably fair... but not being nonce resetted, so continuing its normal increasing, I don't understand how could be not provably fair)... I'd appreciate explanation about, since it's interesting.

P.S. Are you saying I miss the chance to do some cheat to win ? :):):)

A part the kidding, it would be an interesting discussion to understand.

Edited by ivand2128
Link to post
Share on other sites
On 10/18/2020 at 7:39 PM, Dan said:

All API requests used on the frontend of stake.com are already whitelisted. If you wanted to create a custom strategy, you could just use those API requests without needing to go through the process of whitelisting your own. Easiest way to copy them would be right clicking on the page > selecting "inspect" > viewing "network" > limiting to "XHR" > and copying the relevant graphql request

This has always been the most appropriate way to learn about how the site's API works.

Guys.... The answer is already here for all your queries issues ^

Hence that syntax for whitelisted queries is a must be 100% matching.

So what you need to do is just copy the request payload query just like this (use view source or parsed):

image.thumb.png.08f017b58eb6b14be9c33d0e46ee9f7f.png

* Notice that you have to replace the paragraphs characters with "enter" from keyboard if you want to use it for Insomnia or any other query software.

* If you want to use plain query string for your software (example .NET) just use the view source string - plain text with \n

* At Insomnia you can also copy plain text query with the perfect syntax at timeline (in case you have copied it perfectly from the website).

Every query is at Stake's site, you just need to "sniff" the data by using the interface from the Casino site and check which queries are being sent.

 

@ivand2128

User balances: 

Quote

query user($name: String!) {\n  user(name: $name) {\n    balances {\n      available {\n        currency\n        amount\n      }\n    }\n  }\n}\n

Last Nonce (contains User Balances as well) from @Seuntjie:

Quote

query DiceBotGetBalance{user {activeServerSeed { seedHash seed nonce} activeClientSeed{seed} id balances{available{currency amount}} statistic {game bets wins losses betAmount profit currency}}}

Bet Verification (contains Nonce as well):

Quote

query BetVerify($iid: String!) {\n  bet(iid: $iid) {\n    id\n    iid\n    type\n    bet {\n      ... on CasinoBet {\n        id\n        game\n        nonce\n        clientSeed {\n          id\n          seed\n          __typename\n        }\n        serverSeed {\n          id\n          seed\n          seedHash\n          __typename\n        }\n        user {\n          id\n          __typename\n        }\n        __typename\n      }\n      ... on MultiplayerCrashBet {\n        id\n        crashGame: game {\n          id\n          seed {\n            id\n            seed\n            __typename\n          }\n          hash {\n            id\n            hash\n            number\n            __typename\n          }\n          __typename\n        }\n        __typename\n      }\n      ... on MultiplayerSlideBet {\n        id\n        slideGame: game {\n          id\n          seed {\n            id\n            seed\n            __typename\n          }\n          hash {\n            id\n            hash\n            number\n            __typename\n          }\n          __typename\n        }\n        __typename\n      }\n      __typename\n    }\n    __typename\n  }\n}\n

 

Edited by DreamStage
Link to post
Share on other sites
  • Forum Admin

The only time you need to contact us to whitelist something is if you have a custom use case (which is rare) and thats when you can reach out and have a discussion.

1 hour ago, ivand2128 said:

Why not being provably fair ?

When I was changing only client seed, the nonce was NOT resetted to 0, it was continuing increase from original starting of server seed... and, to verify the bets, it was only need to sign the nonce where client seed was changed.

So, how could be it was not provably fair?

(If also nonce was setted to 0, on changing only client, then I agreed it's not provably fair... but not being nonce resetted, so continuing its normal increasing, I don't understand how could be not provably fair)... I'd appreciate explanation about, since it's interesting.

P.S. Are you saying I miss the chance to do some cheat to win ? :):):)

A part the kidding, it would be an interesting discussion to understand.

There is room for deceit on the operator side if you dont rotate both seeds. We pride ourselves in provable fairness and wanted to ensure players get the best possible protection.

Link to post
Share on other sites
51 minutes ago, Dan said:

The only time you need to contact us to whitelist something is if you have a custom use case (which is rare) and thats when you can reach out and have a discussion.

Thanks. Simply after last change, my queries wasn't working... and wasn't working neither after copied newly from frontend, because now them are treated as recognized strings... so even with a single different character, it result in error (for instance, even a different tabulation will lead to error)... and basically I was only missing the empty line at the query end :) . Besides, at starting, in previous topic you was said to post the query error ID in order to be listed, it's because I was asked. But now I found the error, and the way to solve. Thanks again.

About instead....

51 minutes ago, Dan said:

There is room for deceit on the operator side if you dont rotate both seeds. We pride ourselves in provable fairness and wanted to ensure players get the best possible protection.

What you said is dangerous :) , and now you let me begin to be scared, because... if already before (when guest was free to change only the client-seed, right to prevent any deceit by operator) there was room for deceit on the operator side... then now is also worst, because if there is room for deceit on the operator side, then now the guest cannot neither at least try to prevent the deceit changing only the client-seed.

If there was room for deceit before, then there is also now (also more).

So, are you saying that stake/primedice provably-fair algorithm are not 100% sure/safe?

Can you please better clear this 200%IMPORTANT thing?

Basically... can you please provide an example on how before the operator was able to deceit? and how now it wouldn't possible the same thing?

Please clearify this very important aspect, since it's the core of the provably-fair casino. Thanks like always

Edited by ivand2128
adjust
Link to post
Share on other sites
  • Forum Admin
1 hour ago, ivand2128 said:

Thanks. Simply after last change, my queries wasn't working... and wasn't working neither after copied newly from frontend, because now them are treated as recognized strings... so even with a single different character, it result in error (for instance, even a different tabulation will lead to error)... and basically I was only missing the empty line at the query end :) . Besides, at starting, in previous topic you was said to post the query error ID in order to be listed, it's because I was asked. But now I found the error, and the way to solve. Thanks again.

About instead....

What you said is dangerous :) , and now you let me begin to be scared, because... if already before (when guest was free to change only the client-seed, right to prevent any deceit by operator) there was room for deceit on the operator side... then now is also worst, because if there is room for deceit on the operator side, then now the guest cannot neither at least try to prevent the deceit changing only the client-seed.

If there was room for deceit before, then there is also now (also more).

So, are you saying that stake/primedice provably-fair algorithm are not 100% sure/safe?

Can you please better clear this 200%IMPORTANT thing?

Basically... can you please provide an example on how before the operator was able to deceit? and how now it wouldn't possible the same thing?

Please clearify this very important aspect, since it's the core of the provably-fair casino. Thanks like always

Guests where only able to change their client seed via API, we forgot to remove that functionality. As you already stated, it works fine on front-end and the change to that was done a long time ago. There are always risks using an API, especially when you sue a deprecated mutation.

Link to post
Share on other sites
6 hours ago, Dan said:

There is room for deceit on the operator side if you dont rotate both seeds. We pride ourselves in provable fairness and wanted to ensure players get the best possible protection.

I would argue somewhat here. There is room for deceit on the operator side if you rotate only server seed and not client seed. Changing the client seed without changing the server seed, there is no way for the site to cheat. 

In addition, I would argue that letting the site know what your client seed is before they select your server seed leaves room for the operator to choose a server seed with certain properties (cannot have 0 in the first 100 rolls for example).

 

Since the server provides proof that the server seed doesn't change (in the form of the hash), the part that the client has control over has to be set after the client has received the proof of the server seed.

 

In my opinion, the ideal system should generate a random client and server seed when seeds are rotated, and the user/client should be able to set a custom or new client seed without changing the server seed before betting starts on the server seed. Once betting starts, the seed pair is locked until a new server seed is generated. Luckily Stake and PD follows this approach in essence, since your next seed is already generated and you can see the hash before you rotate seeds and set your client seed, and thus is properly provably fair.

Edited by Seuntjie
Added last sentence bit
Link to post
Share on other sites
7 hours ago, Dan said:

Guests where only able to change their client seed via API, we forgot to remove that functionality. As you already stated, it works fine on front-end and the change to that was done a long time ago. There are always risks using an API, especially when you sue a deprecated mutation.

Sorry but this dont replies to the core question. The API is just the way to send the same commands like on frontend (in fact we copy the query API from frontend)... so, I don't understanding what are these risks using your casino?

(Besides, to be exact, there are more risks on the frontend, when peoples using their browsers, rather than using a not-browser program which interact only with server side... while at network level, a sniffer could get info in both cases).

The core question was... if you said that before operator was able to deceit, why now it shouldn't be able in the same way (also more) ?

Can you post a practice example on how operator was able to deceit before? And thus, how now shouldn't be able in the same way?

I was pretty sure there wasn't way for deceit by operator. But if you say that there was room for deceit by operator, then like said, now we're under the same risk (and also more)... so a clear explanation about, could feel us more safe. Since I'm being scared by your post now.

3 hours ago, Seuntjie said:

I would argue somewhat here. There is room for deceit on the operator side if you rotate only server seed and not client seed. Changing the client seed without changing the server seed, there is no way for the site to cheat. 

In addition, I would argue that letting the site know what your client seed is before they select your server seed leaves room for the operator to choose a server seed with certain properties (cannot have 0 in the first 100 rolls for example).

 

Since the server provides proof that the server seed doesn't change (in the form of the hash), the part that the client has control over has to be set after the client has received the proof of the server seed.

 

In my opinion, the ideal system should generate a random client and server seed when seeds are rotated, and the user/client should be able to set a custom or new client seed without changing the server seed before betting starts on the server seed. Once betting starts, the seed pair is locked until a new server seed is generated. Luckily Stake and PD follows this approach in essence, since your next seed is already generated and you can see the hash before you rotate seeds and set your client seed, and thus is properly provably fair.

I'm absolutely agreed with you @Seuntjie.

Exactly! as you explained, if the operator provide its server-seed before than (in the form of the hash... as stake/primedice does) the guest can choose its own client-seed (undifferently if guest changes it more times or not), then it should be provably fair. And me too was thinking so. HOWEVER @Dan said there is room for deceit... so, since I respect his knowledges, his words let me (and may be others too) begin to be scared.

So, if him could provide an example on how, after operator provided seedHash and changing only clienSeed, there was room for decit... then we could understand aslo why now shouldn't be the same.

Since the large amount of hashes that stake and primedice togheter manages (plus all already known hashes over the internet), there is room to think some way could be used for deceits... and in these cases, then change the client-seed would be the only safe way to prevent deceits.

So let's hope he will does clearness about his words... since after his words, I'm not feel safe anymore, like I was before that post.

Thanks.

Edited by ivand2128
Link to post
Share on other sites
2 minutes ago, nikolas666 said:

intresting were you place those codes?

What do you mean?

If your purpose is to create your own play strategy, then you can use whatever programming language and editor you prefer... simply, you'll use the APIs to sent commands to server... thus, whatever thing you use, simply will need to include an http-client to send the APIs to casino server.

Hope this help.

Link to post
Share on other sites
  • Forum Admin
15 hours ago, Seuntjie said:

I would argue somewhat here. There is room for deceit on the operator side if you rotate only server seed and not client seed. Changing the client seed without changing the server seed, there is no way for the site to cheat. 

In addition, I would argue that letting the site know what your client seed is before they select your server seed leaves room for the operator to choose a server seed with certain properties (cannot have 0 in the first 100 rolls for example).

 

Since the server provides proof that the server seed doesn't change (in the form of the hash), the part that the client has control over has to be set after the client has received the proof of the server seed.

 

In my opinion, the ideal system should generate a random client and server seed when seeds are rotated, and the user/client should be able to set a custom or new client seed without changing the server seed before betting starts on the server seed. Once betting starts, the seed pair is locked until a new server seed is generated. Luckily Stake and PD follows this approach in essence, since your next seed is already generated and you can see the hash before you rotate seeds and set your client seed, and thus is properly provably fair.

That is correct, thank you for completing my lazy and somewhat incomplete response.

To summarise and clarify, we removed the old method of rotating seeds individually because of the issue expressed when the server seed is rotated while the client seed is known. During this process we enforced a single rotation seed mutation to ensure proper practice occurred when rotating. In that process, we deprecated the old method (single seed rotation mutations, both client and server) in favour of a single fairness mutation.

That is why the client seed mutation wont work anymore, and my lazy answer to the whole thing was that theirs room for deceit (in the old process, if you only rotated the server seed.) There was nothing wrong with rotating client seed without server, it was just part of an old system that had flaws with regards to the other half of the process.

I often forget that you cant provide lazy answers on such topics xD

 

Link to post
Share on other sites

I was scared by this...

On 10/21/2020 at 3:54 AM, Dan said:

There is room for deceit on the operator side if you dont rotate both seeds.

...since I was referred to change only client-seed.

So, thanks, for better clearify here...

15 hours ago, Dan said:

To summarise and clarify, we removed the old method of rotating seeds individually because of the issue expressed when the server seed is rotated while the client seed is known.

... yes, all agreed... like said, my doubt was born referring to only client-seed. Tx for clearify.

Thus, since...

15 hours ago, Dan said:

There was nothing wrong with rotating client seed without server

... would be great to have API to change only client-seed (single subfunfction surely exists), to have again more strongness against manipulations.

Nothing of absolutely need, but would be great...I simply hope about it.

Thanks again for your clearify.

Best regards.

P.S. I would like make a suggestion...

since betting APIs, taken by frontend, doesn't return balances (and neither nonce), I believe would be good to include also these info on server response when bet is placed... because, who use its own bot, surely create its log with bets details (or money management purpose)... and currently it's need to do 2 requests on server (1 to place bet, and another 1 right after to get balance/nonce details). So I believe it would be good to have at least balances into the same API which place the bet, in order to reduce the workload on server.

(considering a single account may place around 250k bets/day, currently will result as 500k request/day on server... so, it would be saved about 250k request/day on server)

Edited by ivand2128
Link to post
Share on other sites
8 hours ago, ivand2128 said:

since betting APIs, taken by frontend, doesn't return balances (and neither nonce), I believe would be good to include also these info on server response when bet is placed... because, who use its own bot, surely create its log with bets details (or money management purpose)... and currently it's need to do 2 requests on server (1 to place bet, and another 1 right after to get balance/nonce details). So I believe it would be good to have at least balances into the same API which place the bet, in order to reduce the workload on server.

(considering a single account may place around 250k bets/day, currently will result as 500k request/day on server... so, it would be saved about 250k request/day on server)

DiceBots bet call has user balance and seed details included in the response. You might be able to use it instead, I'm just not 100% sure how the GraphQL client I'm using formats and attaches the variables to the query.

 

https://github.com/Seuntjie900/DiceBot/blob/master/DiceBot/PD.cs#L272

 

Edit: Also, you don't necessarily need to request the balance after every bet. You can update your balance internally by just doing balance+=lastBet.profit. Whether the bet was a win or a loss, that'll stay accurate, then just do a balance every 30 seconds for other things that might affect your balance (deposits, withdrawals, tips etc). That's the way most sites work anyway, so if it's good enough for the site, it should be good enough for your bot.

Edited by Seuntjie
Link to post
Share on other sites
1 hour ago, Seuntjie said:

DiceBots bet call has user balance and seed details included in the response. You might be able to use it instead, I'm just not 100% sure how the GraphQL client I'm using formats and attaches the variables to the query.

 

https://github.com/Seuntjie900/DiceBot/blob/master/DiceBot/PD.cs#L272

 

Edit: Also, you don't necessarily need to request the balance after every bet. You can update your balance internally by just doing balance+=lastBet.profit. Whether the bet was a win or a loss, that'll stay accurate, then just do a balance every 30 seconds for other things that might affect your balance (deposits, withdrawals, tips etc). That's the way most sites work anyway, so if it's good enough for the site, it should be good enough for your bot.

Hello Seuntjie, thanks for reply.

I was already saw your 'DiceBotDiceBet' which include balance and nonce into the query, and I also tried to use it, however I have admit that after copy/past it don't work (I've done several attempts checking every single character from your original string -and also applied correct variables taken by Stake.cs file-... all of them, included spaces \n etc, seems to be ok, however it don't work after copy.. so I left). Others of your queries instead (which are written on a single line) works correctly. So I taken only your 'DiceBotLogin' query which include balances, nonce, and some other detail could be useful.

To be clear, I like your DiceBot, and suggest it to all readers who want play dice game... however I stopped to use it several years ago, for few personal reason:

the mainly reason, like said in previous post, is because DiceBot allow to play only on dice game, while I use also others like roulette and baccarat mainly (like you can see in below images); further, I code in javascript, creating also test, optimizations, and complex things (for me :) ), so it's more easy for me the my way; further, I was playing on Luckygames (PD too slow) before it's start to close (where I've done some nice profit on balls game :)... in 2018 I made a crazy thing, which was betting about 80millions of bets per day :)... great %gain in few days :) ); few other reasons.

Multigame.thumb.PNG.a13d6e9bbea79252e73732c904ae10c5.PNG

roulettegame.thumb.PNG.bfcc3b936e59b25e4d83fa49dc0f6844.PNG

About this...

1 hour ago, Seuntjie said:

Edit: Also, you don't necessarily need to request the balance after every bet. You can update your balance internally by just doing balance+=lastBet.profit. Whether the bet was a win or a loss, that'll stay accurate, then just do a balance every 30 seconds for other things

I'm not agreed...

Yes in most cases it's ok, and me too was think so... however in much other cases it's not ok. For instance, especially during the step of test a strategy in real (since test could be performed even not real), that's an important thing to see, which can help you to check everything is ok, or help you to discover problems (in the first above image, I discovered some problems to adjust, right checking the balance bet by bet). Internal calculation can be done anyway, to compare, and check correctness of the code. Further it's also a way to check that doesn't happen nothing strange by server side. Some other cases may be. So, in my opinion, it's an important thing to have bet by bet (in fact you included them into your query :) rightly).

Thus, I hope that play queries which includes balances will be posted... even if, it's the same for me, since I've already solved. Mine was simply a suggestion for the casino, which could reduce the server workload.

Thanks again

Edited by ivand2128
Link to post
Share on other sites
On 10/21/2020 at 2:10 AM, ivand2128 said:

Yes, thanks, like said in updated post, I was solved also about balances, and all other things.

Yes, I was already using that method to get queries by frontend, but since a week now, something was changed... and on firsts attempts, I wasn't able to use the queries getted by frontend... but like said, it was because I was missing a single character (the empty line at the end of the query :) ).

Now I have newly create all commands, to use into my programs.

The only commands that still miss me, which cannot be get by frontend, is:

mutation query to change ONLY client seed.

I had also that command until previous week (before these last restrictions)... and often I was using it. It exists, in fact I still use it on primedice.

So I hope @Dan or someone else will post this other command whitelisted API.

For all rest, I solved, and have all commands now, to use for creation of my own programs.

Thanks

Get queries from frontend (browser devtool>network), and copy the query by there into client you use... but take care to past exactly the same query string, because also a single character different will result in a different string, and will result into an unrecognized query. For instace, take also care that query finishes with an empty line as shown in above images.

Hope you'll solve.

Solved thank you. that was good advice

Link to post
Share on other sites
4 hours ago, CyberMax said:

Dear friend, is it possible to change the number of mines using the code to MINES?

Surely you can code everything you can do normally on frontend website. And you can get APIs right by frontend (devtools>network) like @Dan explained some post above.

Link to post
Share on other sites
5 hours ago, ivand2128 said:

Конечно, вы можете кодировать все, что обычно делаете на веб-сайте. И вы можете получить API прямо через интерфейс (инструменты разработки> сеть), например@Dan объяснил какой-то пост выше.

Разобрался. Вот Это намудрили ЛУНАТИКИ!!!

 

Edited by CyberMax
Link to post
Share on other sites
On 10/22/2020 at 10:20 PM, Seuntjie said:

Edit: Also, you don't necessarily need to request the balance after every bet. You can update your balance internally by just doing balance+=lastBet.profit.

 

On 10/22/2020 at 11:35 PM, ivand2128 said:

I'm not agreed...

Yes in most cases it's ok, and me too was think so... however in much other cases it's not ok.

I have to correct meself... yes @Seuntjie you're right, internal calculation is valid in all cases (except to compare with server side for verify)... so even in particular cases when loss/profit is not exactly the bet amount (like below image), internal calculation can be performed anyway... and, what you written as balance+=lastBet.profit, using the data obtained from server response object, would be: balance+=responseObj.payout-responseObj.amount or using responseObj.payoutMultiplier (keeping in mind right calculation if payoutMultiplier is below 1).

roulettegame.thumb.PNG.3d72e4ae59926fbcc5dfff54f3a3e6f3.PNG

Thanks again for your replies.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...