Would this still work if the owner of the website can create an exact clone of the RAM and read everything (including encryption keys) in there?
Yeah, that doesn't matter. That's actually the attack vector Intel SGX is designed for. It protects against it by encrypting the entire memory space of the application. There's a bit of a performance hit to this (say 15% slower than a program not running in an enclave) but it's surprisingly reasonable. Although your CPU actually does physically contain that decryption key, which in theory could be extracted with physical access. As I understand it though, it's extremely hard to do so with any attempt to physically extract should destroy the data before you can do so. Regardless of the encryption method you suggest, we must still trust that ChipMixer's code running on their server is the same code made available for public audit.
No, Intel SGX provides something called "remote attestation" which you can think of Intel signing a message saying "This specific program, generated this specific value when run in a secure enclave". So if that program (which you verify matches, and doesn't log) generated a public key. You know you can now communicate with that program in a way no one else can intercept the messages. The two immediately obvious pitfalls: a) Intel could potentially be compelled into signing a false-attestation. b) There's security vulnerabilities in SGX which nullify their guarantees (which has happened several times before). Either way though, Intel has probably invested billions (?) into their secure computing so they would be extremely unhappy to see their guarantees fail in the wild. On the Ddos issue if ChipMixer were to put into development a system where you download something and get a public private key pair you can then use to connect to the site over cloudflaee so it's still encrypted however there are a few main issues with this: Users wouldn't need to download anything other than the webpage, which contains a few hundred lines of javascript to serialize/deserialize encrypted messages to the known public key. Then you'd verify the public key matches what people have said actually matches the remotely attested to one.
|
|
|
@ChipMixer have you looked into trying to provide guarantees you're not logging?
I am probably not the target audience, but I am deeply skeptical of mixers. It would seem to me to be negligent of intelligence-agencies to not be running their own mixing services. And as none of the mixers provide any guarantees of not-logging, it seems kind of impossible for a user to know which are honeypots and which aren't.
One feasible way (AFAICT) of proving you aren't logging would be making-public the program that runs on the server. That program would not log (which people can check by looking at the source code) and it would generate a "communication key". Which would be an asymmetric encryption key that can be used to securely talk to the program. Then on your website you make a little light js client which serializes/deserializes encrypted messages from server-side program.
So now the only thing you need to do, is prove the "communication key" was generated by the program. If we know the communication key was generated by the program, then we know anything encrypted to that key can only be read by the program, and we know that program does not log. Now the cool thing is we can use Intel's SGX and remote attestation to actually prove this key was generated by this particular program.
I think put together would give users pretty strong assurances that your service is doing what it claims.
Anyway, food for thought.
|
|
|
The only way to truly beat the house edge is to compromise their backend.
Another possibility is to find and abuse weaknesses of sha256 which is used to generate the game-outcomes and the hashchain itself. There was a guy a while ago, who did some pretty hardcore analysis and was able to find some statistical biases which would make some numbers slightly more likely to come up than others (I forgot the exact conditions though). The biases he found were several million times too weak to beat the house edge, but it's conceivable with a sufficient amount of cryptanalysis you could detect patterns. A question I've often wondered, is if you used a really well-studied and super broken hash function like md5 -- is that sufficiently broken enough that people would be able to actually find abusable patterns?
|
|
|
The Jackpots actually are provably fair
C'mon. It's obviously and demonstrably not. Looking at your code, you've used the bustabit method for calculating game outcomes (good!), but then misapplied the same technique to pick a "jpPlayerRandom". This makes no sense, because you can see it in advance and can control the players who are betting. The litmus test for if something is provably fair, is if you could cheat without players being able to detect it. In this case it'd be very simple to have a house player who wins 100.00% of all bets, and no one would be able to tell if it was legitimate or not. -- FWIW I think there's nothing wrong with having jackpots that are not provably fair, as it's quite difficult to come up with new robust provably fair schemes -- but it's highly unethical to represent something as provably fair that isn't. --- I also think you should address @bsky's question. I'm a little suspicious that you're running a game that is ostensibly -EV, and then misrepresenting something that's not provably far as being so.
|
|
|
The foundation should standardize the length of server seeds, some sites (including some in the foundation) have dangerously short seeds.
Like which? But a short server-seed can't be used to cheat players, but rather allow a casino to be cheated. If a casino can't protect itself by picking an appropriate sized seed, there's probably 1000 other mistakes they've made that could be abused?
|
|
|
I doubt BetKing in its current trust standing (reference: this) is representative of the values CGF stands for. I actually think betking was removed quite a while ago, when they first started doing shady stuff. Which I believe that was even before they reneged on their promise to investors, which is when they fell out of favor on bitcointalk.
|
|
|
How is this any different than a provably fair dice game? Basically the server knows the server seed, nonce and most likely 99% of the time the client seed since many gamblers never change the client seed manually.
So lets say someone is betting on 50/50 and they never change any parameters then the server can know whether they will make money or lose money in the next hundred rolls or so.
The server knows what the outcome will be ahead of time but the server doesn't know if the client will actually take a particular bet. The client can also change the odds which would also change whether the house makes money or not.
I don't quite get what you mean. Provably fair systems just aim to prove the server has committed to a fair distribution of game results. Generally the server will know exactly how well a player will do, assuming it can predict how the player bets (as game results are pre-determined from the fair distribution). But in general, it doesn't really matter much because the provably fair system shows the server has already committed to those results. I guess you could come up with some extreme scenarios, where a whale is playing very predictably and the casino calculates it will probably lose a lot of money so it fakes some maintenance style issues, or requires a mandatory seed rotation to prevent that. I guess it's possible, but I very much doubt that even happens in practice.
|
|
|
First: The game looks good! It beats having just another new dice site  But I can't help being curious why theymos didn't accept your bids to advertise on Bitcointalk. Could you shed some light on that? My guess is because it's a new account? Although digging a bit deeper, it looks like they are run (associated?) with megadice.com which what satoshidice.com was rebranded into. (Although I've not heard any scam accusations against any of those operations, so I don't see why that would be a problem)
|
|
|
Even if there was some way to prevent the operator cheating the investors he could still decide one day to run off with the bankroll. So the bottom line is you have to trust him if you want to invest in his game's bankroll.
You can mitigate that a lot by using a multisig cold storage wallet. That's actually how bustadice works, with the auditor[1] holding (one of 3 keys), he would only authorize withdrawals if the audit checked out. (Which is actually the reason that bustadice only lets you withdraw after you request a new server seed, so the auditor can verify any wins). -- However, if I'm brainstorming and trying to think of attack vectors -- one thing a malicious operator could do is purposely generate a lot of controversy or do something extremely concerning to cause (or make plausible) that investors start divesting en masse. As a key holder, I'd have no choice but to release the funds to process the withdrawals/divestments, and then the malicious operator absconds with the funds. --- That said, I think it still provides significant guarantees to investors -- as there's a huge difference between being able to undetectably steal from investors, and making it blindingly obvious [1] I am currently the bustadice auditor. Although I think I'm probably no longer the best person for it. When I originally became auditor, I was running an established casino and daniel was a competitor to me (*cough*flinch.io*cough*) so it made a lot of sense me being an independent auditor. But on account of after that Daniel buying me out, I would assume most people would question my independence... (which is hard for me to demonstrate)
|
|
|
The set up seems fairly good but any gaming platform where results are known to the owner operator in advance are in essence unacceptable.
It remains a different issue altogether that Daniel retains a high degree of respect by the community in general and more specifically by his investors and game players especially when 400BTC is the figure you used above.
What would have been the complexity involved had a code change been implemented to remove the advance knowledge factor?
It's not really possible. In bustadice, it works like this: The person sends their bet to the game server. The game server sends the bet information to the audit server. The audit server logs that information, and releases the audit seed for that bet. So the audit server knows the full bet details, before the game server even knows the outcome. This what prevents any possibility of undetectable cheating. -- Now going back to bustabit, the game server can't really run the game without knowing when the bust is. So it'd need the audit seed from the audit server. But it also can't provide the audit server with the full bet information, because people can adjust their cashouts in real time. So it'd be pretty straight forward to do if you removed "manual cash outs", but that's a pretty big part of the bustabit experience.
|
|
|
Could somebody explain exactly what Moneypot is? Is it a tool that allows you to spread your investment across multiple site bankrolls to minimize risk? Or what?
I would definitely be interested in such a tool, or something similar. Post it here and you'll get merit if I see it.
The original moneypot was basically a "casino as a service". The old homepage did a good (imo) job of explaining it: https://web.archive.org/web/20151127194540/http://moneypot.com/It was a pretty cool project, made a decent amount of money and had a ton of potential. I just couldn't handle the responsibility of it, and bustabit at the same time -- so decided to sell it. After that it was pretty badly mismanaged on multiple fronts. Some were pretty wtf, like increasing the perfectly configured risk (max of the optimal kelly) to a max of 3.33x that. Even when i provided them simulations that showed an angry whale would guarantee in expected negative bankroll growth and bust the bank, they ignored me. (And no prizes for guessing what came next). There's definitely a few things I'd do differently if I did it again, but I think it was fundamentally a good idea that someone (who is not me) should revive 
|
|
|
Wish i could get my hands on v1 for a good price with a few other from the old family like @jackpotracer, @yahoo and a few other maybe also with the help from RH to bring this great projekt!
I actually think it's a good idea, with a lot of potential. I, however don't want to be involved -- but purely because I don't really want any legal liability being involved in gambling anymore. I however can put you in touch with a developer who did a lot of work on v1, and is pretty familiar with the codebase (he did the untitled dice stuff, the plinko, and sockepot). If you are serious, I'd suggest contacting support@moneypot.com for the exclusive rights on v1 source code and I'll checkin with the old dev to see if he's available. And then you could just relaunch it on a new domain 
|
|
|
If you're going to scam -- you really should put in a bit more effort. No one's going to fall for "I have a super secret exploit that can make hundreds of bitcoin. Instead of using it myself I'm going to risk it being exposed for the low price of 0.46 btc".
I guarantee if you actually had a such an exploit, you could easily sell (responsibly disclose) to Daniel for hundreds of thousands of dollars.
|
|
|
I've been playing a lot with constraint solving (thanks to my work on coinsayer) and when you have a hammer, everything looks like a nail -- so I was thinking of how it'd look if you applied a constraint solver to a bitcoin node's mempool. The goal would be to simplify a lot of the rules, logic and remove the arbitrary limitations and rules that currently exist (that can be both annoying, and pretty incentive incompatible).
So I was thinking, imagine we allowed our mempool to contain transactions that conflict with each other -- as long as they don't conflict with the transactions in the blockchain.
So to figure out which transactions should be in the next block is actually a pretty straight forward optimization problem. Basically find the set of transactions that maximizes the fees subject to it not exceed MAX_SIGOPS / MAX_WEIGHT / have any of the same inputs / and input references to an unconfirmed transaction, must then also include that transaction. You could even throw in a few extras without too much work (e.g. tie break on first seen transactions)
Now lets for a second pretend latency is unimportant (I think it's pretty solvable by running the solver, and caching the and incrementally updating it as an approximation).
So the real tricky part is some anti-DoS stuff. We need to come up with:
A) a rule that would ban a peer for sending us too much crap b) a rule for knowing which transactions are worthy of forwarding to a peer
And we need to do it such that rule b) never causes our node to be banned by someone following rule a)
---
Any ideas?
|
|
|
I can't understand why the hell a gambling project does such a thing.
You have a business which is generating profit in every condition. Why act maliciously?
I don't think he did. He basically had a decent business, and operated it honestly (to the best of my knowledge) and shut down and returned everyones money. Then later, he saw the wtf ICO craze and decided he wanted in on some of that sweet cash. So he came up with some phoney reasons for needing money, ICO'd and relaunched. Then he was too cheap to use the ICO money for anything so instead of paying for a bustabit license, pirated the software. Instead of putting money in the bankroll, started accepting separate bankroll investors. And the relaunched site isn't a viable business, beside it's pretty much is dead (1300 btc wagered total, ~2 of those in the last week) and with such a garbage name. But hey, Dean's sitting pretty (i bet he net a few million from the whole ICO scam) and just needs to leave his zombie site limping along for a couple years, so he can pretend i was just a normal case of a business-gone bad; and in the mean time he can work on his bitsafe or what ever next ICO he wants to scam people with.
|
|
|
The naive way of constructing this makes it then take 20 minutes computation to verify, which isn't that attractive if you imagine the verifier is some lame mobile client and the attacker is a mining farm.  Yeah, although in my case it was totally fine. As it's not really required (or expected) that everyone verifies, it's just an option if you want. And had the nice property of being drop-dead simple  I keep seeing people propose this an their proposals always turn out to be totally broken, but in fact there is a way to do this that I call tapering.
Step 1. A block is 3xVDFed to pick a random value. Step 2. The next block is 2xVDFed to pick a single bit: if it's one, go back to step 1 for the next block. Step 3. The next block is VDFed to pick a single bit: if it's one, go back to step 1 for the next block. Step 4. The last step 1 outcome is accepted.
This will terminate in a couple steps on average.
Oh, I see. That's pretty clever, never thought of something like that.
|
|
|
And it was documented after the wager contest that ALL bets were rolled back and all players got their balances reset. No player lost any money. I did as some players withdrew winnings during the contest.
It's weird that you consider that acceptable. It's almost like you don't understand how a casino works.  BTW Can you give a straight answer to why you rolled everything back and didn't pay out the wager prizes? Or simply because it was cheaper than paying out?
|
|
|
Also, it was stated very clearly, even in the posts you reference, that the tokens were denominated in $ so no idea where you think there was an extra $12 million.
You're being rather disingenuous. Just because the tokens were priced in USD, doesn't make the crypto magically disappear. I'll stress again, as fact, no one has lost any money (unless you chose to sell at a loss). You realize that applies to pretty much every single scam out there, right? There is no scam (if you bought stock and it dropped 60% is that a scam? If you bought btc at $20,000 and it dropped to $8000 is that a scam?) You're framing it like people are attacking you for losing money. But the truth is that you structured the ICO to give you exposure to bitcoin price. You were happy reaping the profits when it worked in your favor netting you significant amounts of money, and then renegged as soon as it worked against you. That's what makes it a scam, and you a scammer. -- BTW I dare you to stop all the nonsense deflection and try give a straight answer to something like this: https://bitcointalk.org/index.php?topic=4751127.msg51398067#msg51398067
|
|
|
1. Only use blockchain as entropy source when the cost to manipulate blockchain is higher than it's "reward"
It's worth noting that you can increase the cost of manipulating the blockchain. For instance I used to run a lotto, where I'd use a bitcoin block hash to determine the winner. However, because the prizes were reasonably big compared to the blockreward it would've been (very) profitable for a miner to manipulate. So I stretched the hash with an operation that might take like 20 minutes or something. That made it pretty impractical to manipulate the lotto (after finding a block, a miner would have to wait 20 minutes to check if it was good or not), unless the miner was prepared/able to 51% attack bitcoin at the same time  2. Use many blocks in a sequence as entropy source since it's difficult to manipulate n blocks in a sequence.
How does that work? If you get n blocks in a sequence -- the result is always going to be influenced by the last block in the sequence, who would be able to perform the same sort of attacks as if you just had used that 1 block.
|
|
|
I brought this up almost 2 years ago. This is what BetKing.io answered: So what I meant is if someone wants to sell me 10% of their tokens I will buy them. I can't say sorry I'm only going to buy 4%. ( archived) Dean, how about you directly address this? I now wonder if Dean really believes his own lies, or he just made so many lies he can't keep them consistent anymore?
I think his strategy is to just argue semantics and nonsense to the point people either give up, or assume he might have a point. It's getting pretty hard to interpret his stuff charitably. There was a post a couple months ago where that BillyBurns guy (some moderator and investor) said that Dean lost all his money altcoin trading. I have no idea if it's true, but say it was and Dean just came out and said: "Hey guys, I'm sorry but I got stupid and lost all the money on altcoin speculation. As such, I am am bankrupt and not in the position to payback investor. However, I really don't want to totally screw investors so I'll be working as hard as I can on the site to make more money to try make investors whole". If that was the case (not implying it is...) it'd be easy to cut him some slack and say "ok, he fucked up badly but at least he's trying his best to right this situation". But honestly I suspect he had good intentions at the start. He made a lot of money and was really happy. But when the price moved against him realized that he was going to lose some of that unrealized profit, and wasn't ok with it -- so just changed the terms of BKB with some pretty half-thought-out excuse for screwing investors.
|
|
|
|