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)  

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.

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 

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

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



Oh, I see. That's pretty clever, never thought of something like that.

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?

You're being rather disingenuous. Just because the tokens were priced in USD, doesn't make the crypto magically disappear. 



You realize that applies to pretty much every single scam out there, right?


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

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




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.

Dean, how about you directly address this?


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.