Monero dice seed hacked?

[NLNico]

Perhaps a comparison will help: let's say that you have 10 BTC in Poloniex. You hear that Poloniex isn't processing BTC withdrawals, along with panic that they're hacked, and use your BTC to buy a bunch of WaffleCoin and withdraw it. You sell your WaffleCoin on ShapeShift, but now the market's tanked and you end up with 9 BTC. Later that day Poloniex put out a statement apologising for the issues and stating that they're now fixed. Would you insist that they roll the trades back? What about the shorters that took profit from you?

Strange comparison.

Better comparison: a hacker steals a part of the balance from very specific accounts on Poloniex. In panic, I obviously withdraw the left-over money. Poloniex detects the vulnerability and refunds all money. I think it would be normal that Poloniex refunds the affected balances and not just anyone on Poloniex. I just cannot imagine Poloniex saying "well, I know you lost money because of that hacker, but you withdrew the rest, so we won't give your lost money back, instead we give it to others".

Of course if I gamble with the "left-over money" on a dice site and loss it all, then I don't expect them to pay that part back (which is your comparison.) But that has nothing to do with the hacked losses.

Or what if you invested in a startup, and then when it looked like things were going south you sold your investment at a loss. Two years later the startup is a huge, successful company. Do you insist on taking profit from the growth because you *used to be* an investor?

Strange comparison again. It has nothing to do with future profits. We are not talking about an investor who is complaining that you made huge profits after he divested. We are talking about investors who made a loss because of a cheater when he was invested and you are refunding the wrong people.

Better comparison: if one of your employees stole money directly from investors during the time I was an investor of that start-up and he would refund 2 years later, then yes, I would still expect him to pay me too.

You stated at the outset that you understand that the situation would have been different had the attacker managed to withdraw, but you're not actually following that thought through. Had that played out we'd have a total loss on the part of all the investors, and one investor who only incurred a $100 loss, and you can bet that investor wouldn't volunteer to divvy up his remaining funds among the affected investors.

What? Let's say the cheater would have won 50% of the BR, I divested to cut losses, and cheater continues to win rest of BR. Then yes, indeed, I would only have a 50% loss, while others would have a 100% loss. That's exactly right and that's why someone should divest/withdraw when he sees the site is hacked. I don't see why that investor with 50% loss would owe anything to the other investors?

Even then, you would have the decision to try to do the right thing and refund the losses (so 50% to the 50% loss dude and 100% to the rest). But in that situation I could have understand saying "sorry investors, but that was your risk too and I cannot pay you everything so we have to sort something out". That is why I say that it depends on the situation. Still I would expect any refund to go to affected investors who had a loss and not just to any investor after the cheater.

We thought about this, but we decided that it would be too dangerous for us to spend days and weeks trying to build a magical "undo" script, completely wrecking any auditability, and potentially ending up with a screwed up data set at the end.

Why? You would do these calculations on a separate database and only calculating the refunds, not too much risk. Yes, it might take a few days (although a quick script for estimations should be possible in a few hours.) But I don't see why a little more delay would be a problem if it's doing the right thing.

What happens when someone "accidentally" places a large bet and loses? Should we undo their bet, and take the profits from the investors?

Lol what? We are talking about a cheater who won money, what has that to do with someone losing money? Obviously when a player bets, it's final. No dice site ever refunds any normal bet.

An investor that divests and withdraws is no longer part of the bankroll.

It's not about the bets after he divested, it's about the bets during his investment. You refunded the bets that were during his investments. He was a part of the bankroll during that time, so he should be refunded.

Nevertheless, I've already offered to send $100 to the affected investor, so I'm not sure what more you expect?

I would expect you to understand why it's wrong to refund the current investors and not the affected investors. And I would hope you pay back the affected investors because it's the right thing to do as a gambling site owner - not because $100 is not much.





I am honestly surprised about the replies here. I have been following your site for months and had a pretty high opinion of it since you are a trusted XMR developer. But I really cannot imagine that you don't understand why you should refund investors who actually had a loss because of the cheater.

[1714963894]

1714963894

[1714963894]

1714963894

[BillyBurns]

 Fluffy I agree with a lot of what Nico has said. I would like a refund because I do believe I should have received one, but I do not want the refund if you believe it to be out of charity. I want it because you believe its the right thing to do. If you change your mind could you credit it to  my account.

[fluffypony]

What? Let's say the cheater would have won 50% of the BR, I divested to cut losses, and cheater continues to win rest of BR. Then yes, indeed, I would only have a 50% loss, while others would have a 100% loss. That's exactly right and that's why someone should divest/withdraw when he sees the site is hacked. I don't see why that investor with 50% loss would owe anything to the other investors?

So you're of the position that other investors, who may be asleep due to timezones, should just suffer the 100% loss? So in that event the investor is just "lucky", and the rest are "unlucky"?

And yet in the reverse all investors should be "lucky"?

How do you not see the disconnect here?

I am honestly surprised about the replies here. I have been following your site for months and had a pretty high opinion of it since you are a trusted XMR developer.

lol sure, that's why we're listed on DiceSites, right? Don't patronise me.

[fluffypony]

Fluffy I agree with a lot of what Nico has said. I would like a refund because I do believe I should have received one, but I do not want the refund if you believe it to be out of charity. I want it because you believe its the right thing to do. If you change your mind could you credit it to  my account.

We're always open to discussing things like this, and finding an amicable solution for everyone. That's why we have an email address that you can use. Having a messy ideological discussion on troll central is not a fantastic way to achieve that, especially given that we *are* responsive to support emails.

[NLNico]

So you're of the position that other investors, who may be asleep due to timezones, should just suffer the 100% loss? So in that event the investor is just "lucky", and the rest are "unlucky"?

Yes, because of this:

An investor that divests and withdraws is no longer part of the bankroll.

Besides that, this is an extreme scenario because it assumes that you had the whole bankroll in a hot wallet. I don't see too much reason to consider extreme scenarios like that, better to just look at the facts. With the manual withdrawals in place, it would have been no problem to refund 100% to the most unlucky investors and 50% to those who lost 50% etc.

And yet in the reverse all investors should be "lucky"?

No, just the ones who had a loss and were in the bankroll during the time of the bets.

How do you not see the disconnect here?

No, seems very rational to me.

I am honestly surprised about the replies here. I have been following your site for months and had a pretty high opinion of it since you are a trusted XMR developer.

lol sure, that's why we're listed on DiceSites, right? Don't patronise me.

That is exactly why I have been following your site indeed, to consider to add it on my site. For what it's worth: I am very transparent about that and I only add the most popular sites (which don't have a history of untrustworthy behavior.) Your site used to have plenty of days without any betting, so normally that wouldn't qualify. I have seen a rise in play since the XMR price rise, so I definitely was planning to add your site to the new version of my site. But I agree this is all not relevant to this situation.

[RHavar]

We already have a replayable log (that's the point of the MySQL log after all), but we couldn't rewind the entire system. Consider, for instance, a new user that created an account and deposited funds. If we roll the system state back we would have to manually allocate all of those and manually recreate the users. And, too, consider the exact issue we've got above, where a user divested and withdrew - how do you roll that back? You can't, so you have to move forward with the system in the current state.

::sigh::

That's just rolling back the database, and not what I meant at all. A replayable log is logging all the individual events (e.g. bets, investments and divestments), in such a way that if you found a mistake had occurred (or in this case, fraud) you could fix the mistake (in this case, delete the bets) then replay everything so the investors balance is exactly is if the fraud never occurred in the first place.

It's actually just a good practice to be in, when ever I mutate state I *always* store the cause of it. (e.g. if someone transfers money, I log an event of the transfer. If someone claims the faucet, I store the details of that, if someone invests I store a record of it (and things like how much the bankroll was before they invested) etc).

And probably the other mistake people make, is over-constraining their database to not allow negative values. e.g. While a user balance never should be negative, the system should support it as cases like this might cause some accounts to legitimately be negative (them withdrawing gains they shouldn't have) or even deposits reverting after a blockchain reorg etc.

It's great for a disaster recovery situation like this, and it's great from an audibility perspective. It's probably too late for this time around, but it might be worth designing around in the future.

[BetKing.io]

We already have a replayable log (that's the point of the MySQL log after all), but we couldn't rewind the entire system. Consider, for instance, a new user that created an account and deposited funds. If we roll the system state back we would have to manually allocate all of those and manually recreate the users. And, too, consider the exact issue we've got above, where a user divested and withdrew - how do you roll that back? You can't, so you have to move forward with the system in the current state.

::sigh::

That's not what a replayable log is, at all. A replayable log is logging all the individual events (e.g. bets, investments and divestments), in such a way that if you found a mistake had occurred (or in this case, fraud) you could fix the mistake (in this case, delete the bets) then replay everything so the investors balance is exactly is if the fraud never occurred in the first place.

It's actually just a good practice to be in, when ever I mutate state I *always* store the cause of it. (e.g. if someone transfers money, I log an event of the transfer. If someone claims the faucet, I store the details of that, if someone invests I store a record of it (and things like how much the bankroll was before they invested) etc).

And probably the other mistake people make, is over-constraining their database to not allow negative values. e.g. While a user balance never should be negative, the system should support it as cases like this might cause some accounts to legitimately be negative (them withdrawing gains they shouldn't have) or even deposits reverting after a blockchain reorg etc.

It's great for a disaster recovery situation like this, and it's great from an audibility perspective

Exactly, see http://martinfowler.com/eaaDev/EventSourcing.html

Note that even if you don't follow strict event sourcing best practices you should still have a log of everything anyway so that you can replay, just takes more effort. Surely each bet/invest/divest actoin must have a timestamp on his MySql rows?

[raphma]

Custom API, so I don't think this affects anyone else. We've disabled betting in the meantime whilst we sort this out, but I really think the lesson to other operators is not to be overconfident in your code or in your setup. Everything can and will be compromised, so assume it's going to happen and put safeguards in place to handle that eventual scenario.

Do you think it could have been compromised a long time ago? Maybe the hacker got tired of milking it and just went for a big score.

It's entirely possible, but one of the Monero Research Lab wrote a paper (for fun) a year ago establishing a way to analyse whether someone is cheating by determining whether they are massively changing the deviation of the site.

We run this analysis in the back all the time, so if someone was consistently cheating, even if they were using multiple accounts and small amounts, we'd see it show up because the site would (statistically speaking) be far out of the expected variance.

You can read the paper here: https://lab.getmonero.org/pubs/MRL_Monte_Carlo_Edition.pdf

Even with small amounts? imagine if he were doing 2 losses for every win, but, every win he bets 3~5 times the lose value.
statistically, this wouldnt be almost impossible to find and with small amount it would be even harder.. any way, everything on internet have vulnerabilities.

[fluffypony]

We already have a replayable log (that's the point of the MySQL log after all), but we couldn't rewind the entire system. Consider, for instance, a new user that created an account and deposited funds. If we roll the system state back we would have to manually allocate all of those and manually recreate the users. And, too, consider the exact issue we've got above, where a user divested and withdrew - how do you roll that back? You can't, so you have to move forward with the system in the current state.

::sigh::

That's not what a replayable log is, at all. A replayable log is logging all the individual events (e.g. bets, investments and divestments), in such a way that if you found a mistake had occurred (or in this case, fraud) you could fix the mistake (in this case, delete the bets) then replay everything so the investors balance is exactly is if the fraud never occurred in the first place.

It's actually just a good practice to be in, when ever I mutate state I *always* store the cause of it. (e.g. if someone transfers money, I log an event of the transfer. If someone claims the faucet, I store the details of that, if someone invests I store a record of it (and things like how much the bankroll was before they invested) etc).

And probably the other mistake people make, is over-constraining their database to not allow negative values. e.g. While a user balance never should be negative, the system should support it as cases like this might cause some accounts to legitimately be negative (them withdrawing gains they shouldn't have) or even deposits reverting after a blockchain reorg etc.

It's great for a disaster recovery situation like this, and it's great from an audibility perspective

Exactly, see http://martinfowler.com/eaaDev/EventSourcing.html

Note that even if you don't follow strict event sourcing best practices you should still have a log of everything anyway so that you can replay, just takes more effort. Surely each bet/invest/divest actoin must have a timestamp on his MySql rows?

Guys, you don't know our system design, you don't know our architecture. Even if you did, you can't possibly have all the facts of the matter. The continuous string of commentary is entirely pointless - the decision is not going to be made again, we've already moved past it.

And yes, we have timestamped logs for every single action, every single bet, every single investor credit, every single investor debit.

[NLNico]

You can say that, but it is still completely unacceptable. Just a TL;DR for those who didn't follow (simplified example but exactly what happened):




Imagine there are 4 investors with each 100 XMR, so total BR is 400 XMR. Cheater comes and wins 200 XMR, leaving all investors with 50 XMR each. 3 of the investors decide to divest to limit the amount the cheater can win (but the cheater doesn't bet anymore.) Owner luckily processes all withdrawals manually so is able to stop all the withdrawals including the one from the cheater (and from any investor, if temporarily needed.)

Now the owner has 2 refund options. Give 50 XMR back to each investor (who were invested at the time of the cheater.) This way, there is literally no loss for anyone. Or give all 200 XMR to the 1 investor that is left, so he can profit from the situation. The first option seems 100% obvious to me. And the second option is basically just scamming the other investors. You chose the second option and somehow still doesn't understand why it is wrong.





Don't even start about "what if", Poloniex or start-ups, the above is exactly what happened (with different numbers obviously.)

Am I the only one who thinks this is just unacceptable?

[DarkDays]

I don't have any skin in this game but imo the way FluffyPony/Monero is handling this is incorrect.

Someone tried to steal a bunch of money.  They were caught.  That money should be RETURNED TO THE PEOPLE WHO IT WAS STOLEN FROM!  Saying "We're not going to return the money that was stolen from you because" and then any reason is horrible and wrong.  So they divested?  Irrelevant.  They still had money stolen from them and keeping that money for yourself is a Very Bad Decision.  Who cares if figuring out who the money belongs to if a complex situation?  That's on you as the owner of the site, the person who allowed this money to be stolen, and the person who is making risk-free money.  This is your job.  Do it.

[BillyBurns]

I was paid back in full and left with the impression they would  not handle the situation in this manner again.

[Pif]

...
Am I the only one who thinks this is just unacceptable?

No, and it is clear for what I already wrote in this thread. I understand that not being in their shoes and without the pressure of the moment to take a decision is easier but saw some bad attitude and thinking process here.

Anyway glad to see they decided to do what they should and fully refunded BillyBurns.

[ndnh]

I think probably it is added back to the investors at the time of adding back. So if someone divested, he won't get anything, but if someone invested, he would get a share of the added back amount

Yeah, that's how it sounds like. Actually when I designed the moneypot investment system, what I did was create a repayable log of all the investment/divestment/bet events for in a nightmare situation like this (or software bug) it could be replayed so investors wouldn't have made/lost money from the changes in the bankroll when a fake better (or software bug) was playing.

The situation is probably a big mess now, as some investors have lost more than they should've and others made more than they should've. And it's probably pretty likely the ones who unfairly made money have already withdrawn (?) or at the very least, will be unhappy if their balance gets put to the correct amount

The log is a pretty good idea. I don't think there are many casinos here that have such a mechanism, probably just Moneypot.

https://bitcointalk.org/index.php?topic=1366689.msg13969066#msg13969066 did they use the log when they removed the duplicate bets, or did they just add or subtract it back to the latest balance pro rata? I assume the latter because it is much easier?

So then you cut your losses and you get out, the end. There is no coming back later on to try reclaim imagined profit.

Perhaps a comparison will help: let's say that you have 10 BTC in Poloniex. You hear that Poloniex isn't processing BTC withdrawals, along with panic that they're hacked, and use your BTC to buy a bunch of WaffleCoin and withdraw it. You sell your WaffleCoin on ShapeShift, but now the market's tanked and you end up with 9 BTC. Later that day Poloniex put out a statement apologising for the issues and stating that they're now fixed. Would you insist that they roll the trades back? What about the shorters that took profit from you?

Or what if you invested in a startup, and then when it looked like things were going south you sold your investment at a loss. Two years later the startup is a huge, successful company. Do you insist on taking profit from the growth because you *used to be* an investor?
-snip-
We thought about this, but we decided that it would be too dangerous for us to spend days and weeks trying to build a magical "undo" script, completely wrecking any auditability, and potentially ending up with a screwed up data set at the end.
-snip-
With all respect to the affected investor, he took his $100 loss and walked away. He didn't contact us, he didn't ask for input on how we were going to handle things. He just assumed that it was the end, and he would have been the *only* investor to get out with his money had we not had safeguards and had the attacker been able to actually drain the wallet. What would have happened then?

I disagree with almost all of the examples. You cannot consider all your investors as a single entity.


Well, if you can set the investor's balance as would have if this guy didn't make the bets, it will be the best thing to do, especially if the amount added back is of a significant amount to the bankroll.

If you cannot, however, well...

Anyway, did you make certain you could not add it back in a fairer way?



To be honest, I considered investing once I read

Looks like they managed to grab the server seed through a leak in the API - we're busy patching it, and will rollback the naughty bets. Thankfully we process every single withdrawal manually, and most of the funds are all locked up in a cold wallet, so no money was lost. It's precisely because of the very high risk of an exploit that we don't let withdrawals process automatically!

(I didn't though) so I can't say the adding back was very   fair. Anyone paying attention could guess well in advance what was gonna happen and make a profit.

Nevertheless, I've already offered to send $100 to the affected investor, so I'm not sure what more you expect?

That is nice

[SparkedDev]

Oh good to hear you fixed it.
Looked like some test bets then hits.

[adi33]

if you've sent an email to admin ?. maybe it is in the hack. because first there was gambling sites were hacked. but in my opinion this is not because the systems in which errors in hack

[BitMaxz]

Looks like its just a bug not a hack because the gambler is gamble in normal until the 3 result  from nearly end are bug..
It is a large amount of monero if this is true and i think they should contact the support and maybe they give some rewards to say that than withdrawing it because like other said its manually withdrawal..

[BillyBurns]

Looks like its just a bug not a hack because the gambler is gamble in normal until the 3 result  from nearly end are bug..
It is a large amount of monero if this is true and i think they should contact the support and maybe they give some rewards to say that than withdrawing it because like other said its manually withdrawal..

Look at the bets, look at the bet sizings, looks at the results of the bets and the sizings together. If you cant see it let me know so I can face palm.

[Zadicar]

Looks like its just a bug not a hack because the gambler is gamble in normal until the 3 result  from nearly end are bug..
It is a large amount of monero if this is true and i think they should contact the support and maybe they give some rewards to say that than withdrawing it because like other said its manually withdrawal..

Look at the bets, look at the bet sizings, looks at the results of the bets and the sizings together. If you cant see it let me know so I can face palm.

They cant really see it  , i could say  that theres  no dice seed  hacked with these  bettings   its jsut  pure  luck  though, We cant really believe  it  hence these are  huge  winnings with  low  winning rate  seems  not  too common for us  thats  why  we could really say   theres an exploit.

[Febo]

Why do you even care ? If he is clever and can hack then shame for you. He found a way into the system so good for him. Ga!nbling sites mostly bitch so its good to see someone got them back.

Well actually this gambling site seems quite fair.

I have few XMR invested on bankroll or however is it called. I invested over a year ago so quite soon after start and so far gained 4.5%. If i remember right half should go to casino and half to bankroll owners.
This shows how little players actually lose.


Oh and i had no ideas this happened   You can imagine how surprised i was reading it here.
Lucky me all went well and illegal bets was stornated and lucky me i had no ideas what was going on and I did nto do something stupid as withdraw XMR.