I don't really know anything about vipgame.io or much about EOS. But using the hashes as a source of entropy seems like a kind of terrible idea, and I believe was the root cause of how EOSPlay was "hacked" yesterday.

I think you could be a bit more diplomatic, but I agree with your general point. Sites like AskGamblers are pretty parasitic, and happily push super dodgy sites like bitstarz (whose M.O. seems to be try find any reason to not pay out large winners) as long as they have a sweet ref program.


It's not perfect, but I've found https://cryptogambling.org to have the best curated list of (crypto-accepting) casinos.

That's absolutely not how entrapment laws works or are intended to work. Firstly (although the specifics vary per country) you almost universally you have to demonstrate you would not normally have done the crime if it wasn't for the persuasion or trickery of the police. No joke, the police have quite literally operated a child-pornography site as a honeypot and without extenuating circumstances entrapment is simply not a defense.

But more importantly, if it was a honeypot it would be used for evidence gathering, rather than charging you with a crime per se.

I think you really need that remote attestation to make it useful. I'm not sure, but I suspect AMD/ARM probably have similar things, but not sure about the process. For Intels you need to register, but I don't think that's an issue (and it's free)



Actually seems up for me, just supppppper slow. So probably a big long-lasting DDoS (ugh, fuck the internet )

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.



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.




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.

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?

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.

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

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.

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)

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)  

You need to be careful to not put the cart before the horse. Bustabit is a casino, which happens to allow investors to participate in the bankroll.  It's not an investment scheme, which people can gamble against.

Bustabit is already provably fair for players, so adding additional guarantees for investors isn't going to help players at all (perhaps only indirectly via encouraging a larger bankroll) so I think it'd be a critical mistake to compromise by doing something like removing manual cashouts to create a more robust investor scheme. Bustadice was fortunate in that it was able to add the additional investor protections, because it came at negligible cost to players (slightly slower bets, due to the RTT to the audit server -- and a little more complex provably fair system to verify).

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.

No. Daniel knows all future game results, so it could be undetectable abused to cheat investors.  It's probably not happening though, considering investors are ~400 BTC ahead of expected value. But no real way to be sure, you have to 100% trust Daniel, basically.

Bustadice however, has actually a pretty neat system you can look at. There the game results are created by a combination of: (server seed, auditor seed, client seed) so it would not be possible to undetectably cheat investors without the auditor noticing (or participating).

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  

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 

Another question: Do the jackpots come out of the crowd-funded bankroll? Or is that something that comes out of a fund provided by you? 

Now that you're replying, could you answer why you never paid out the christmas-wager-promotion and instead chose to roll back bets? Was it you didn't have the money, or didn't want to pay, or there was some legitimate bug people were exploiting or something? Just curious.