Is this a bug?. This should win (hilo original)

[blockbet]

The reason this happened is because your client submitted the result using the "lower than" operator rather than "lower than or equal to". Which means you were more than likely using some form of automation tool to play as its not possible for the unmodified  web client to submit using just the lower than operator in a scenario like this. If this bug occurred while using the web client, it would be occurring for everyone. You should update your bot logic to use the lower/greater than or equal to operator (<= and >= respectively) so that you don't lose rounds unnecessarily when the next card is equal to the last. Technically the result you were provided by Stake was correct, at least based on your submission. In terms of code/logic stability, it shouldn't allow you to submit a result using greater than/less than.  Something like this should have been caught by their CI/CD pipeline via unit tests before it was released to production environment. Probably didn't due to insufficient code coverage/not writing comprehensive test cases. But then again, they probably wouldn't be in any rush to fix such an issue as it only occurs when using third party tools to access the API - something they seem to be against.

Also, its not possible for them to disable the API. The whole site operates from a single graphql endpoint via web client. What they've done is made schema publishing private, so people cant just see all of the possible queries and mutations. You can still figure most of them out though based on how your browser forms the requests normally. Just takes more effort.

[cocmeu]

22 hours ago, blockbet said:

The reason this happened is because your client submitted the result using the "lower than" operator rather than "lower than or equal to". Which means you were more than likely using some form of automation tool to play as its not possible for the unmodified  web client to submit using just the lower than operator in a scenario like this. If this bug occurred while using the web client, it would be occurring for everyone. You should update your bot logic to use the lower/greater than or equal to operator (<= and >= respectively) so that you don't lose rounds unnecessarily when the next card is equal to the last. Technically the result you were provided by Stake was correct, at least based on your submission. In terms of code/logic stability, it shouldn't allow you to submit a result using greater than/less than.  Something like this should have been caught by their CI/CD pipeline via unit tests before it was released to production environment. Probably didn't due to insufficient code coverage/not writing comprehensive test cases. But then again, they probably wouldn't be in any rush to fix such an issue as it only occurs when using third party tools to access the API - something they seem to be against.

Also, its not possible for them to disable the API. The whole site operates from a single graphql endpoint via web client. What they've done is made schema publishing private, so people cant just see all of the possible queries and mutations. You can still figure most of them out though based on how your browser forms the requests normally. Just takes more effort.

Bla bla bla. How was this client able to send this dissonant result if the API is not available for general users?

Modify the results in a technically complex outcome that's hard for even experienced developers? It's just ridiculous from what I can see, if what you're saying is even possible.

[blockbet]

13 hours ago, cocmeu said:

Bla bla bla. How was this client able to send this dissonant result if the API is not available for general users?

Modify the results in a technically complex outcome that's hard for even experienced developers? It's just ridiculous from what I can see, if what you're saying is even possible.

Well because you have to submit your input to the server in order for it to determine if you won or lost that round. As I stated in my original post, this isn't something that will occur if you are using the standard web client as it's set up to use the proper operator. However, if you use some third party client to play the game, you're obviously the responsible party for making sure that the data is properly sent. The data you submit to the server for a game event in hilo is essentially just the selected operator (greater than, less than, greater than or equal to, lower than or equal to). Due to this, it's important that you submit the proper operator. Also, for clarification, the OPs client never modified the result. The result is hashed on the server and is pre-determined when you select your seed pair. It's not possible to modify a provably fair game result without replacing the seed pair. Doing this would cause verification to fail while checking your results after selecting a new seed. What the OPs client did was improperly send the input selection which is compared with the predetermined result to see if the player won the round or not. You can technically submit anything as your input, however the endpoint has validation so that only properly formed data is accepted, the rest will throw an exception. It didn't throw an error here because the operator used could have been a valid response in other scenarios.

I'm not saying the way it's currently developed is proper or I agree with how the mechanics work here - I'm just stating the known facts so people can understand what happened in this scenario. If you'd like to know how it should work if it were properly developed, one simple solution would be to depreciate the use of the greater than / less than operators and only allow greater than or equal to/less than or equal to. There shouldn't be any scenario where using "or equal to" would affect the result in an unexpected manner since its an "or" statement rather than "and". This would also make it very easy to sanitize any bets submitted by the client since any bets made without the equal to operator would be considered invalid and would immediately throw an exception without any processing time. The reason why it would be difficult to set up error handling explicitly when the wrong operator is used is because the server would need to compare the last card result with the current card in order to determine whether using "or equal to" is proper for the particular situation, and this isn't something that can be efficiently done at the time of receiving the players input from the client.

This post is probably TMI for most, but I wanted to give the OP a conclusive explanation as to why this occurred so they don't think it's just some hocus pocus. To sum things up, this would not have occurred had the OP been playing the game normally. I can just about guarantee you they were using some sort of third party tool or bot to place their hilo bets - hence the reason why the wrong operator was submitted. This would be the fault of whoever developed the software being used. I'm not saying it's bad or wrong to use a bot to play, but rather if you decide to use a third party client, you should make sure you test it thoroughly before using it for real. Stake should also fix this on the backend, however I doubt they ever will or even care for that matter. 

Hopefully this helps to understand how things work with APIs as well as Stakes game logic for hilo. Since Stake doesn't seem to be proactive about fixing such things, it's in your best interest to try and understand stuff like this in order to maximize RTP potential on games you bet on regularly. This way you don't give away money to the casino unnecessarily due to  something that could have been prevented. The more you know.

 

- Dash

[Blackshires]

Hello,

Not sure why people always think API is disabled, Stake itself provide the API token, and a lot of players use it (i use it every day for sport betting).

Since the cloudflare protection, it's a little bit more difficult to access it ( you have to bypass cloudflare, but you'll find easy how to do in you prefered language ( python for me).

Yes Stake itself use the API, you can see each request (F12->Development options,...), look for the graphQL request, and here you can find the paypload ( "what to send"), and the url. You just have to send the X-Token in the header of your request, and it work like a charm.