|
Can you sign 14iS2UvcLK33xkC1K1qL1dhEbp49aiNfNp?
If that's you, your description of the exploit doesn't match up with the official version published by the casino.
|
|
|
|
|
See ff0f3368-d64e-44b6-bafc-877c648f3a56. Should probably fix that.
|
|
|
|
The Roulette game is programmed by a third-party developer.
I can't answer you about this situation now because we don't know the full code of how is made, but our developers are checking this situation and will come back with more details as soon as possible.
After a month and a half, it seems likely that your developers have had a chance to look in to this. Can you provide an update? |
|
|
|
|
I'm glad you're looking in to this, though I wish my original post had been answered so that maybe the flag and negative trust could have been avoided. In a PM, you asked for additional information. I don't think there is much else that I can provide other than what is in this thread. I hope you are able to find and correct this problem, and I expect that correcting this problem will include paying out all won bets incorrectly reported as lost.
|
|
|
|
Would you mind explaining the results of the following bets?
869601854
869602054
869602352
869602473
The result of bet id 869601854 is as follows: {
"id": 869601854,
"game": "Roulette (EU)",
"slot_name": null,
"slug": "roulette-eu",
"slot_slug": null,
"slot": 0,
"currency": "BTC",
"options": {
"20": "10.000",
"66": "10.000",
"67": "10.000",
"89": "10.000",
"101": "10.000",
"124": "10.000",
"125": "10.000",
"135": "10.000",
"136": "10.000"
},
"data": [
26,
[]
],
"payout": "0.00",
"amount": "0.003362466992",
"profit": "-0.003362466992",
"hide_bets": 0,
"username": "Acer64",
"xp": "900.00000000",
"datetime": "12 Oct 2023 22:18:22",
"avatar": "8",
"avatar_bg": "f34135",
"avatar_builder": 1,
"server_seed": "2ca25f3eeb0cce84690cbad69c61a991101135d8d795e3821cfda55251bb8e1d",
"client_seed": "d64b8399a89512",
"reveal": 1,
"nonce": 2,
"server_seed_hash": "e4fb55e2493e8cca556690c91bd22d1050a83dd6c50c328fb111d5ceeb9efd5f"
}The first value of the data array is 26, and this is the value recorded as having been the result of this Roulette game. At https://cryptoplay.io/help/fairness, the following code is available to check your provably fair implementation: $seed = hash_hmac('sha512', 'my server seed', 'my client seed'.':'.'my nonce');
$seed = hexdec(substr($seed,0,10));
$roulette_number = $seed % 37;
return $roulette_number;I wrote the following Node.js adpation of the PHP code: const crypto = require('crypto');
const hex = crypto.createHmac('sha512', 'd64b8399a89512:2').update('2ca25f3eeb0cce84690cbad69c61a991101135d8d795e3821cfda55251bb8e1d').digest('hex').substring(0, 10);
const res = parseInt(hex, 16) % 37;
console.log(res);This code indicates the result of the game should have been 21, which would have been a winning result for this particular game. The results of the next bet in this series, bet id 869601961, follows: {
"id": 869601961,
"game": "Roulette (EU)",
"slot_name": null,
"slug": "roulette-eu",
"slot_slug": null,
"slot": 0,
"currency": "BTC",
"options": {
"20": "10.000",
"66": "10.000",
"67": "10.000",
"89": "10.000",
"101": "10.000",
"124": "10.000",
"125": "10.000",
"135": "10.000",
"136": "10.000"
},
"data": [
8,
[]
],
"payout": "0.00",
"amount": "0.003362466992",
"profit": "-0.003362466992",
"hide_bets": 0,
"username": "Acer64",
"xp": "900.00000000",
"datetime": "12 Oct 2023 22:18:28",
"avatar": "8",
"avatar_bg": "f34135",
"avatar_builder": 1,
"server_seed": "2ca25f3eeb0cce84690cbad69c61a991101135d8d795e3821cfda55251bb8e1d",
"client_seed": "d64b8399a89512",
"reveal": 1,
"nonce": 3,
"server_seed_hash": "e4fb55e2493e8cca556690c91bd22d1050a83dd6c50c328fb111d5ceeb9efd5f"
}
We see here that the reported result of this bet is 8 and can confirm that result with the code written above. Lastly, it's noted that this behavior disappears once below a certain bet threshold. For instance, the bets in this post are all around $90 and a winning bet was never seen in a sequence of 10 bets that should have had about a 25% chance of having some return. Of course 4/10 bets actually did return, the casino just misreported the actual outcome. This behavior was not seen at bets closer to $10. I assert that this casino is fraudulently marking winning bets as losses in a very obvious and easily confirmable way. For that reason, I am leaving a flag. |
|
|
|
|
Would you mind explaining the results of the following bets?
869601854
869602054
869602352
869602473
|
|
|
|
37 please.  |
|
|
|
1. Is it ethical to ask for KYC docs at withdrawal? Please don't point me to ToS. If you need KYC to stop AML, why don't you make it mandatory at deposit itself? If you don't need KYC for small amount, but need it for large ones, why not provide a clear warning on Stake wallet, that beyond X amount here, whether through deposit or winning, KYC will be required?
It's probably illegal for a casino to discuss the exact values that trigger their AML procedures. I do agree that KYC should be done up front and if a casino does not want to take a user's action for any reason, the bet should be refunded and allowed to be withdrawn. That said, I believe Stake is saying that they've had real losses from the match fixing action by this particular user and is holding the balance to recoup some of their losses. That seems reasonable. If Stake has it wrong, Baskin198 should start arbitration. See https://stake.com/policies/terms#17._Arbitration. 2. A match can be fixed. But, without police investigation, an user's involvement in it can't be proven beyond doubt. So, why not have a clear policy that if Stake is informed about a match fixing, all winning and losses will be refunded to individual users? Holding an user's winning as hostage, because of an event that can never be linked with him beyond doubt, is probably not ethical. Also, if Stake is informed, that the matches were fixed, along with freezing Baskin198's fund, will you refund the money to individuals who lost in those matches? If yes, will you publicly announce that refund, so that users can actually confirm the refund in this forum?
You make a good point here. Casinos do seem to like to double dip with these unusual situations, keeping losses and refusing to pay out wins. I don't see any indication that this happened at Stake for these particular events. If someone could show evidence that they placed a losing bet that was not refunded on any of the events that Stake is saying were fixed, then maybe Stake would deserve some criticism. I think that they should codify how fixed matches will be handled in their terms of service to avoid any future confusion. |
|
|
|
They blocked my bet
Can you elaborate on this any? What event did you bet on, how much did you want to bet, was the bet accepted and then cancelled or was the bet not allowed to be placed at all? If you tried to bet 100% of your deposit and the casino turned away your action, then I'd argue you met any wagering obligation. If you can prove that happened, I'd support a flag. That said, the only reference to a wagering obligation I see on the duelbits.com site is the following: After a user deposits funds to Duelbits using any depositing option provided by the company, except CS:Go Skins, there is a minimum percentage of the amount that must be wagered until a withdrawal for the said funds is requested, otherwise the company reserves the right to ask for any additional KYC documentation and freeze the user’s funds until the KYC requirement is fulfilled.
Did they ask you for KYC documents and did you cooperate? I would ask them to point out the specific part of their agreement that they are trying to enforce. If it is this section, ask them to define "minimum percentage" and consider trying to meet that obligation. If you have provided KYC documents, then I'm having trouble seeing their position. I would consider supporting a flag based on this interpretation of their terms of service if you wanted to make that argument. |
|
|
|
And I also would say, if anyone immersed the coin ane let it sit inside the solution, it would smear the ink as well on the private key.
That's what I thought would happen, but it didn't. The ink was definitely degraded but legible. This was a 1 BTC brass Casascius. And if anyone REALLY wanted to get to a Cas private key, why not make the same Hologram and find a blank Cas and use the new hologram?
I think this is the most obvious and likely exploit. |
|
|
|
There's some more information here: https://www.reddit.com/r/Bitcoin/comments/1jouqt/casascius_physical_bitcoins_cracked_at_defcon/. Note the top comment and the statement that the ring didn't affect the exploit. I tried this around that time with dielectric solvent rather than non-polar solvent and it worked okay. I set the coin in a bath of solvent instead of using a needle. The sticker had a lot of residue that would have needed to be cleaned up if I wanted to reuse it, while it looks like the non-polar solvent left the adhesive useable. I didn't have the patience to try to clean the sticker and reapply it, but I think it could have been done. If this was happening, I think we probably would see some indication in the near decade since the exploit was publicly demonstrated. Still, good to be cautious. |
|
|
|
I had the following input on their original topic: This site is not processing withdrawals, no surprise there.
Manual cashouts over 10x are not handled correctly. If a player manually cashes out at 10.5x, they will receive 0.5x resulting in a net loss. This problem does not seem to exist with the auto payout feature. I have not tested 3 or 4 digit multipliers.
The game leaks the server seed before the completion of the game. Normally I would discuss this problem with the owner of the site, but I do not think the owner of the site is acting in good faith. Some code follows to exploit this leaky server seed problem. It can run with a single account labeled account 2 in code, but will run better with two accounts.
---
I've removed the exploit poc. Apparently their crash game script is used at other casinos.
|
|
|
|
Lol, well nice pull, todayiwin. If you want to put your skills to use without the potential of going to jail, send me an email at cwil0290@gmail.com. |
|
|
|
This is a fun topic. I'm a security researcher and actively look for exploits in casinos and other crypto spaces daily. I can't give nonpublic details, but I can talk about some of the more common things I find. The BitMillions exploit detailed here ( https://bitcointalk.org/index.php?topic=386711.0) was publicly known for a few days before the site operator fixed it. Keno, lottery, and bingo games tend to be vulnerable to similar exploits. Craps games from various operators are often vulnerable to two different but similar attacks sometimes seen in physical casinos. A large pass bet is placed on the come out roll and then picked up or significantly reduced if a point is set. Alternatively, a small don't pass bet is placed and then increased and odds laid depending on the point. For example, if the point is 4 you might increase your bet 100x while if it's 8 you might leave the bet alone. These types of slightly +EV rather than instant win exploits are among the most sought after for bad actors as they generally look like normal gameplay. Games in which multiple bets are placed on a board like roulette or sicbo can often be exploited. A developer will perform a sanity check to see if a bet falls within its limits and this prevents a person from placing negative losing bets. The proper way to do this is the check that each individual bet falls within limits, but sometimes a developer will take the sum of all bets and make sure it's above some minimum. This means you could place a bet of -90 on 0, 50 on red, and 50 on black to usually make 90 units per bet. You might also lose 3340 units if the ball hits 0. There may be ways to mitigate or eliminate that downside, such as betting a negative on -1 instead of 0. Various casinos and development studios have been vulnerable to this. Sports betting sites are not immune to exploits either. Odds on single events can sometimes be manipulated in favor of the operator, so not very useful, but parlays can sometimes be made with the same event multiple times. The most dangerous exploits I've found are pf seed leaks. These come in a few flavors. In the early days of bitcoin, dice sites would often generate a file with multiple years worth of daily seeds which were used site wide. The scheme here was hash(server seed + client seed + global bet number) to find the winning number. A popular dice site was vulnerable to a directory traversal attack which allowed the seed file to be read. As another example, there is a crash script available now that leaks the server seed whenever a player does a cash out. To exploit, a person sets up two accounts, once places the minimum bet and cashes out immediately, while the other places a large bet, waits for the cashout message of the first player, finds the outcome of the game from the leaked seed, and cashes out immediately before that point. |
|
|
|
OP, please make more visible the update about the payment  You can use [ hr ] for spacing/separation too. I've modified the first post in this thread to make the update more prominent. |
|
|
|
The phrase "one of my accounts" should be interpreted as an account opened at Cloudbet. I can not say if I have opened an account at Cloudbet before the day in question prior to 2018. I began keeping better records and can say that I have not opened an account since March of 2018. An account opened at Cloudbet does not eliminate the possibility that there was another account in the past that you forgot about. Like you said, you only started keeping proper records in 2018. Based on Cloudbet's reply, they did suspect that it was a matter of multi-accounting. And those things can happen if you are using VPNs. In the end, it looks like this will end on a positive note. Nothing has been proven and the bookie has decided to settle the matter. I do not dispute the possibility of another account, but I sincerely do not know if I ever made one prior to the account in question. I can't go in to much detail about my tooling much like I suspect Cloudbet won't want to go in to much detail about how their risk detection system works, but I can say that with high confidence, regardless of how much telemetry Cloudbet collects, the machine and individual Cloudbet saw that day were brand new. It's very likely that the only thing that triggered the KYC request was the use of the VPN. We're getting a bit off topic here, but if that's wrong and Cloudbet did not see that visit as unique, I would happily take that data in lieu of the 0.005 BTC refund mentioned upthread. To be clear, that's not a challenge or taunt, I truly am interested and would love the opportunity to improve my methods. Cloudbet, please PM me if you want to pass that info along instead of the refund. Cloudbet has processed a refund as discussed upthread. I've withdrawn my flag and revised feedback as agreed. |
|
|
|
I have a question for cwil. In the reference link you posted, you said: Cloudbet suspended and KYC'd one of my accounts created using a popular VPN service pretty quickly after a small initial deposit. What do you mean with "one" of your accounts? Does that mean that you have multiple betting accounts on Cloudbet? And are you accessing all or some of those accounts with a VPN? Someone correct me if I am wrong. Even if the account that was suspended didn't make any bets, maybe some other accounts that you have (since you said "one account" got suspended) did. If that is the case, you ( the person, not the one suspended account) would be in breach of their TOS because you were betting from a restricted location. I am not accusing you, I am just trying to interpret your words properly. The phrase "one of my accounts" should be interpreted as an account opened at Cloudbet. I can not say if I have opened an account at Cloudbet before the day in question prior to 2018. I began keeping better records and can say that I have not opened an account since March of 2018. I do not concede that I have ever placed bets from a restricted location as defined by Cloudbet's TOS. 7.1.4. We reserve the right to conduct such checks at any time as we deem necessary to verify our compliance with clause 7.1.3.
7.1.6. You authorise us to use any means that we consider necessary to verify your identity and creditworthiness with any third party providers of information.
So, OP isn't giving priority to those terms and haven't done the KYC verification. I'm wondering why he (OP) is accepting a small part of the terms by ignoring the first few parts of it. I accept terms 7.1.4 and 7.1.6. These terms state that a user will not be physically located in the listed countries and that Cloudbet may use any means necessary to collect my information in order to enforce 7.1.4. These terms do not compel me to provide information. Even if you do think they compel me to provide information, the remedy for a violation of their TOS is found in section 11, specifically 11.1 and 11.3. The only part of the agreement in which fund confiscation or the freezing of funds appears is in reference to opening multiple accounts, discussed above, or by placing a bet from a prohibited jurisdiction, which didn't happen and Cloudbet does not seem to be arguing otherwise. Absent that criteria, per the TOS, account closures include a refund of deposited funds. The problem arises when you use a VPN with an IP address from a restricted country.
...
In this particular case, OP used a VPN from a restricted location.
I used a VPN located in Canada, this is not a restricted country per the Cloudbet TOS. However both of them (@OP and @Cloudbet) were active, but none of them response to the recent post. We need to hear more about the @OP using multiple accounts, VPNs, etc and @Cloudbet's review against his account. OP might not be aware of the recent posts here unless he has subscribed to a bot that notifies him about mentions and quotes, or if he isn't tracking new posts in his own threads regularly. The Cloudbet admin knows about this for sure. I PMed them asking if they can comment here. But Cloudbet might not be interested in revealing what they have or what they suspect OP is doing until they have gathered all the required evidence. The way things stand now, OP is the one who needs to react if he wants a chance to get his deposit back. I do not frequent this part of the forum and was unaware of activity in this thread until today. My goal was and still remains to warn others about what I feel to be Cloudbet's poor customer service and inability to abide by their TOS, not the return of the deposit, as I indicated in the reference thread in the first post of this thread. What is the purpose of asking for someone's documents if they have already stated that they want to close the account and get their deposit they never used for any betting on the site back? How do you know that OP has never played on Cloudbet before from other betting accounts? How do you know where OP is from? How do you know which country OP was in when he accessed the account or accounts in question? You don't. I don't either. Check the bolded part I posted above in the quote from OP. Cloudbet probably doesn't either, hence the questions and requests they have. Cloudbet's silence in this whole matter is a negative thing. That's true. But the issue will surely not get resolved without OP doing what Cloudbet has asked for, no matter how unfortunate and unpleasant it is. Yeah, you have a good handle on the situation as I see it. Cloudbet wants information that I don't want to provide. I will quote the reference thread: Let me preface by stating that I'm not looking for any resolution on this. I'm a security researcher reporting unusually poor customer service and adherence to a company's TOS.
I've been pretty up front in that my goal is to report my experience. The only question I have is whether they have the right to request KYC verification on people who never have, and never will consume their services? I assume there must be some law prohibiting that. It is something else if the OP is suspected of having multiple accounts, but I have not seen it mentioned anywhere.
BTW, Despite Cloudbet being active again today, there has been no response to this case.
I believe that they have the right to request KYC from anyone they like, and anyone has the right to refuse that request. Hi all, Thank you for your messages. After reviewing this case, we can see that as mentioned: an account was opened, a deposit was made, and no bets were placed. Based on our review, KYC was requested due to suspected multi-accounting which was flagged by our internal systems. As stated in our Cloudbet terms and conditions7.1.10.2. Only one account per customer/IP/household is allowed. If you attempt and/or successfully open more than one account, all of your accounts may be blocked, suspended or closed and any Cryptocurrency credited to your account frozen. Our team have reached out to the player privately, and hope to resolve this issue as quickly as possible. Many thanks, Cloudbet Team Cloudbet did reach out to me in a PM, which is what brought me here. That message is as follows: Hi cwil,
Thank you for your patience whilst we looked into this issue.
After reviewing your case, I can see that our internal systems flagged your account for a number of reasons resulting in our customer support team requesting KYC documentation – this is standard procedure as multiaccounting is in breach of our terms and conditions.
With that being said, we want to resolve this issue and will be returning your original deposit of 0.005 BTC to you – our team will be contacting you via email with further details.
Once payment has been received, we’d appreciate it if you could resolve the flag on our account as we now consider this settled.
If you have any questions, please let me know.
Kind regards,
The Cloudbet Team
I've not yet received this email but I am agreeable to the terms stated in the PM. |
|
|
|
The claim to be licensed/verified by bustabit should be followed by solid evidence. No evidence of the claim = BS as what you say.
That's easy enough, see: https://www.bustabit.com/license.txt. |
|
|
|
|
This site is not processing withdrawals, no surprise there.
Manual cashouts over 10x are not handled correctly. If a player manually cashes out at 10.5x, they will receive 0.5x resulting in a net loss. This problem does not seem to exist with the auto payout feature. I have not tested 3 or 4 digit multipliers.
The game leaks the server seed before the completion of the game. Normally I would discuss this problem with the owner of the site, but I do not think the owner of the site is acting in good faith. Some code follows to exploit this leaky server seed problem. It can run with a single account labeled account 2 in code, but will run better with two accounts.
---
I've removed the exploit poc. Apparently their crash game script is used at other casinos.
|
|
|
|
|
Show Posts
