NLNico





Offline



Activity: 1876

Merit: 1264





DiceSites.com owner







LegendaryActivity: 1876Merit: 1264DiceSites.com owner Re: Monero dice seed hacked? October 19, 2016, 08:57:11 AM

Last edit: October 19, 2016, 09:14:51 AM by NLNico #41 Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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.



Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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.



Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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.



Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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.



Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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.



Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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.



Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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. 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 "".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 payback (which is your comparison.) But that has nothing to do with the hacked losses.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.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 "". 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.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.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.It's not about the betshe divested, it's about the betshis investment. You refunded the bets that werehis investments. He was a part of the bankroll during that time, so he should be refunded.I would expect you to understand why it'sto refund the current investors and not the affected investors. And I would hope you pay back the affected investors because it's theto 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. DiceSites.com ' List of dice sites w/ statistics, graphs & provably fair verifiers '

AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW ertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sites are not endorsed by the Bitcoin Forum. Theymay be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

BillyBurns



Offline



Activity: 430

Merit: 263







Sr. MemberActivity: 430Merit: 263 Re: Monero dice seed hacked? October 19, 2016, 09:17:11 AM #42 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. *Image Removed*

RHavar



Offline



Activity: 2128

Merit: 1670









LegendaryActivity: 2128Merit: 1670 Re: Monero dice seed hacked? October 19, 2016, 01:15:16 PM

Last edit: October 19, 2016, 01:26:51 PM by RHavar #46 Quote from: fluffypony on October 19, 2016, 06:01:02 AM 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. ::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



Offline



Activity: 1288

Merit: 1018









LegendaryActivity: 1288Merit: 1018 Re: Monero dice seed hacked? October 19, 2016, 01:26:49 PM #47 Quote from: RHavar on October 19, 2016, 01:15:16 PM Quote from: fluffypony on October 19, 2016, 06:01:02 AM 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

::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



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?

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



Offline



Activity: 350

Merit: 250









Sr. MemberActivity: 350Merit: 250 Re: Monero dice seed hacked? October 19, 2016, 02:45:50 PM #48 Quote from: fluffypony on October 18, 2016, 09:49:09 AM Quote from: Jungian on October 18, 2016, 09:42:57 AM Quote from: fluffypony on October 18, 2016, 09:33:22 AM 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.

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:

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

statistically, this wouldnt be almost impossible to find and with small amount it would be even harder.. any way, everything on internet have vulnerabilities. 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

Legendary



Offline



Activity: 1274

Merit: 1057





GetMonero.org / MyMonero.com







DonatorLegendaryActivity: 1274Merit: 1057GetMonero.org / MyMonero.com Re: Monero dice seed hacked? October 19, 2016, 07:01:12 PM #49 Quote from: BetKing.io on October 19, 2016, 01:26:49 PM Quote from: RHavar on October 19, 2016, 01:15:16 PM Quote from: fluffypony on October 19, 2016, 06:01:02 AM 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

::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



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?



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. 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. [MyMonero - transact with Monero anywhere, any time] [OpenAlias - the simple, secure alias standard]

NLNico





Offline



Activity: 1876

Merit: 1264





DiceSites.com owner







LegendaryActivity: 1876Merit: 1264DiceSites.com owner Re: Monero dice seed hacked? October 20, 2016, 02:23:36 AM #50 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?

DiceSites.com ' List of dice sites w/ statistics, graphs & provably fair verifiers '

Pif



Offline



Activity: 153

Merit: 18







MemberActivity: 153Merit: 18 Re: Monero dice seed hacked? October 20, 2016, 08:31:16 AM #53 Quote from: NLNico on October 20, 2016, 02:23:36 AM ...

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. 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



Offline



Activity: 1288

Merit: 1001





New Decentralized Nuclear Hobbit







LegendaryActivity: 1288Merit: 1001New Decentralized Nuclear Hobbit Re: Monero dice seed hacked? October 22, 2016, 06:13:33 AM

Last edit: October 22, 2016, 06:29:52 AM by ndnh #54 Quote from: RHavar on October 19, 2016, 02:22:15 AM Quote from: ndnh on October 19, 2016, 02:19:29 AM

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

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.



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?









Quote from: fluffypony on October 19, 2016, 07:52:39 AM 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

Quote from: fluffypony on October 18, 2016, 09:11:47 AM 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.





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



That is nice 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?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(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.That is nice

BillyBurns



Offline



Activity: 430

Merit: 263







Sr. MemberActivity: 430Merit: 263 Re: Monero dice seed hacked? October 24, 2016, 12:49:31 AM #58 Quote from: BitMaxz on October 23, 2016, 11:51:17 PM 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. 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. *Image Removed*