Hacker News Reader

Comment by justonepost | Hacker News Reader

Lol. They (as any sane Casino operator would) should have booted this guy immediately on day 1, claiming they felt he was scamming the system. Sure, pay him out, but don't let him keep betting. Yeesh. I have to wonder if this was an inside job and they let him siphon those winnings. I am highly suspicious of most bitcoin companies, and I wonder if they're all just shells around vulnerabilities looking to siphon user deposits / investments.

View on HN

That doesn't make much sense.

If they have a legit exploit, then kicking them will just make them create a new account. Or perhaps distribute the +EV betting over a bunch of accounts so that it was much harder to detect.

If they don't have an exploit, then you want them to keep betting and lose. And if you have no real basis for kicking them, then, what, your casino just doesn't pay out people that win big?

The casino's only real option here was to discover the exploit.

No, pay him out, but just don't let anyone bets that way continue betting. Betting that rapidly has to be a huge flag for even the dimmest of sys admins.

What is "bets that way"? It seems like initially all they knew was that some accounts were unusually active (betting every second, for hours) and implausibly lucky. They saw the flags, they just didn't know any useful way to react (which is also incompetence, but IMO different than what you said.) (I'm assuming a dumb rate-limiting solution would be off the table, as it would be ineffective at stopping the attack, and/or lose money as other players stop betting when they hit a limit.)

> What is "bets that way"?

I dunno, maybe anyone who is clearly automated (ie, betting every second for hours) and probably cheating (ie, implausibly lucky)?

> It seems like initially all they knew was that some accounts were unusually active (betting every second, for hours) and implausibly lucky.

Exactly.

> They saw the flags, they just didn't know any useful way to react

The useful way to react would be to not let them continue betting.

But how do you reliably identify one anonymous entity? Like I said, putting a rate limit is going to turn away legitimate bettors (if too strict) and not make much of a dent in the attacker's profits (if not strict enough). Doing an "implausibly lucky" check is going to piss off legitimately lucky winners who might have given you more money (if the limit is too conservative), and/or not hurt the attacker much. Any per-account limits can be circumvented by the attacker making more.

Maybe they took some measures like this that they didn't tell us about. With that much money at stake, maybe "do something, anything" does make sense -- my point was there's no way for them to ultimately prevail until they understood/addressed the root issue, and knee-jerk responses could backfire.

From the article:

> There was also strong incentive for us to promptly pay him, so he’d keep playing.

I loved that line, because it's the converse of a casino player in a hole, thinking maybe they can make it back if they keep on playing.

Well, the entire difference between the house and the player is that the house has the edge, so the house always wants the player to indefinitely recycle their winnings until they have none.

It's more than an inverse in thinking, it's how the house makes money.

No, it's the same thing as the dumb guy in a hole. They already know this guy has an edge over them. The more he plays, the worse that gets.

But, as you pointed out, they can't ban him, because they have no way of recognizing him when he walks back in.

Oh, as in Stunna was gambling that the player didn't have an exploit and that the developers were drawing the right conclusion. I'll allow it. :)

Reply on news.ycombinator.com