Comment by genericuser | Hacker News Reader

Comment by genericuser | Hacker News Reader

Parent Full thread

"To understand how Hufflepuff beat our system, one must understand how our provably fair system (RNG) works."

"Our database had seeds that were both inactive and in use at the same time all connected to Hufflepuff."

To me it sounds like your company simply didn't understand how the system you created worked, it sounds like you merely understood how you wished it to work. Gambling has always favored people who actually understand the system in place, by not understanding the system you yourselves were implementing you created the opportunity for a customer to understand it better than you. What you describe with your database having seeds that were both in use and inactive at the same time, sounds to me like you did not do a good job managing concurrency on records which were crucial to your business.

While I can not say whether the users did anything illegal, the post you have created to call attention to this does not make an adequate case for wrong doing on the users part. However your response does make an amazing case for you having responded to an implementation issue in your software very poorly, and I think would make future users who are aware of this less likely to use your service.

That is just my opinion given the information you have presented, as you seem to focus more on maliciously providing information of the person you are accusing as opposed to proving your accusations that the person in question committed a crime while doing so.

I'd be willing to place a bet on what sort of database technology they weren't using. Hint: it has three letters, starts with an S, and ends with an L. ;-)

Unfortunately just using SQL doesn't mean your system is free of race conditions nor that every atomic domain operation is implemented atomically.

Of course, it's a great start.

SQL won't force you to respect flag columns in your application layer (unless your entire application is in SQL?).

The way a student is taught to model something like this is to have the 'seed' entry refer to the 'account' entry (or, better yet, the 'game' entry). This is just how one models a one:many relationship. It is then trivially true that a given seed will only be used in one game at a time. As long as one never updates the reference on an existing seed, a seed can't be re-used in this way.

Of course, relational data models only encourage this type of design: they do not require it, nor are they required for it.

Also, this is by no means the only possible bug of this nature. For example, the seed generation might be based on the current wall-clock time. I'd hope someone trying to run a casino would know better than that, but hopes of that nature are frequently unfulfilled.

From the article it sounds like constraints could have been used to prevent having multiple seeds linked to the same account?

Yeah, I guess it depends on how good your constraints engine is versus what your constraints actually are. If your actual constraints can't be modeled, or if you choose not to model them at the database layer (e.g. for performance reasons) then you have to implement the constraints somewhere else.

I worked on a database that allowed (almost) every table to mark a row as deleted with a boolean-type column. This caused problems when you wanted to create a new row that had the same values for the table's key-columns as a deleted row. You can't just add the deleted column to the key and have all the functionality you want (multiple deleted rows with the same values in the table's key-columns). Each table could use (or not) the flag in different ways and there was no simple way to enforce consistent behavior across all tables. The constraint has to be placed somewhere else, either in explicit code, or by creating new abstractions inside the database that allow you to represent the actual constraints of your application.

There are benefits for marking a row as deleted w/ a boolean column though. Undo-ing deletes would be easy to implement, and retaining references to deleted records would be simple as well.

The solution the problem you described would be to use a surrogate key column (typically a UUID/auto-increment), and not natural keys.

There are reasons for everything in the database. Undo and historical records were the primary use case.

All tables had a unique, integer primary key.

However, if you want to enforce a uniqueness constraint across your data [eg. UNIQUE(name, location)], the constraint breaks when you introduce the boolean deleted column [and UNIQUE(name, location, deleted) does not provide the appropriate semantics]. The application semantics must be provided at some other level than SQL column constraints.

Ah, another gamble. How nice.

So, let's see if I get this. Three letters, that means 1/26th chance of getting the correct number. And.. wait, what do I do now?

Now you submit all twenty six guesses via proxy accounts, allowing for random delays between each guess to appear less suspicious.

Reply on news.ycombinator.com