I'm always interested in provably fair systems, but I don't see how this is remotely is. The first problem is there's a real lack of information/example (as in a concrete example specific to the game), which makes verification more or less impossible even if it was provably fair. But besides that, I don't even see how the method you are using even attempts to solve the problem.

So as I understand it, at a high-level you're trying to do something like:

* Server generates a server-seed
* Server gives clients a hash of the server-seed (to prove it doesn't change)
* Each clients provide the server a client-seed after they've seen the server-seed hash

And then the game result is computed as a function of (ServerSeed, ClientSeeds).

---

If I'm understanding right, that doesn't solve anything at all -- because if any client was controlled by the server, it could pick a client-seed that will make it win.

--

The only way you're (sanely) going to get a game like this to be provably fair, is have each client have a secret -- send a hash of the secret to the server (which broadcasts to all other clients). Then when the client has seen the hash of all other clients seeds, reveals it's own seed. Then the game result is computed based on all the client seeds.


P.S. I'll PM you a security problem i (think i) found

P.P.S. How come your site says there's 470 people online? Surely that can't be real?

I've removed my feedback, as the provably fair system is way better now! Thanks for doing that.

I would however still argue that it's done really extremely badly, with client seeds being generated on the server. This is also compounded with by the fact that changing the client seed is annoying (e.g. arbitrary restrictions of things like min 10 character) and the "randomize" button again is getting the results from the server.

Client seeds really really should be generated on the client (after the client has seen the server commit to a server-seed hash), and then sent to the server.

But anyway, at least you can set your own client-seed -- so it's possible to work around the flaws in system. So I guess it gets a pass

---

But I'd strongly recommend looking/copying the provably fair of sites like just-dice, primedice or bustabit. They're all a little different, but really the benchmark you should be aiming at. They also handle cases like "getting a new server seed" a lot better, because the user should also be (at least prompted) to provide a new client seed, not just reusing the old one etc.

You don't really need consensus for a soft-fork, just the majority of the hash power and there won't be a chain split (pretty much by definition).

As I understand it, the name "orphan" comes from the idea that the idea that the block has no (known) parent. Hence it's an orphan. But when most people say "orphan block" what they mean, is just that it's not (or no-longer) part of the "best" blockchain.

Nodes might cache stale/orphan blocks for performance reasons, but there's no conceptual need to do so. There's no reason that nodes should knowingly relay a stale/orphan block (but the p2p network is a wild-west, so all nodes should expect it to happen)

Sure, I'd be happy to review it. As long as the user can set it, it should be fine. And I'd also strongly advise that the server should **never** generate a client seed. If you want a default one, have the client generate it automatically (after seeing the server-seed-hash) and send it to the server. So from the user-point experience point of view it's the same, just the generation is happening client-side.

With that, it should be all good 

I think the better explanation is:

If you go through the verification process for each individual bet, then each bet is actually provably fair. But if you don't do that process for each individual bet, then it's impossible to verify the bet later. They also know which bets you are able to verify or not. So from their point of view, they know exactly which bets they need to behave with (0.00001% for nerds like me who verify) and which bets they have free-reign to undetectably cheat.

This doesn't prove they're actually cheating, just they have the opportunity to do so without anyone having proof. Which more or less defeats the purpose of having a provably fair system in the first place. If I was a betting man, I'd however bet they are abusing this to cheat. Basically because of the stats BitwiseOperator gave -- and they talk about their nonce system:


But it's 100.00% useless! It literally does nothing other than making it look like the industry-standard provably fair system (which requires a nonce) but it's not!  This to me also seems pretty suspicious.


Personally I'd strongly caution people against playing here...



I would hope that after this (regardless if they were honest or not) they immediately switch to the industry-standard provably fair system (AKA copy exactly what just-dice.com does).

Yeah, but they're probably not. If they did rig it, they would only be able to manipulate the first ~few bets in a sequence (because the nonce system makes it implausible to find a malicious server-seed to rig more than a few bets in a sequence) and more importantly: they would've be vulnerable to someone knowing they're rigging and betting the opposite way.

It's definitely no where near as severe as the wixiplay one (they can rig virtually every bet, and can do it risklessly) but it's still garbage for a provably fair system.

Basically the simple-version is:

* wixiplay uses a unique server-seed per bet (and thus unique server-seed-hash per bet)

* To verify a bet, you need to record the sever-seed-hash *BEFORE* you bet (that way you know they didn't change the server seed in response to your bet)

* To get the the server-seed hash you have to go out of your way and specifically request it, for that bet

---

So what this means, is wixiplay knows if you're able to verify the bet or not. If you're not able to verify the bet, it has free-reign to undetectably cheat!


--

If BitwiseOperator played 523 coin-flips and only won 199, his maths is probably correct (I don't actually know off-hand to do that calculation, so I tried to simulate it. After 200 million simulations, it appears to only happen every 1 in ~5 million times, so it's definitely an (expected) real freak occurrence. )

Combined with the fact they're using a *totally pointless* nonce , makes me feel like they're trying to (maliciously?!) pass their system off their system as a traditional provably fair (which it's definitely not).

Just tried the site, and the half a dozen bets I made did checkout in the provably fair system. You can view the "server seed" by double-clicking on the bet-id of the previous bets you made.


But it looks like a really stupid system. There's no absolutely no reason they should be changing the server-seed each bet (makes it so difficult to be impractical to verify a bunch of bets). And the way the system is now, the nonce serves no purpose at all (other than also complicating verification). But it does appear to be give you enough to verify your bets, if you go through an impractical ceremony.

--

But then it hit me!


They can actually check if you're going through the impractical ceremony on not! I verified this by checking the network requests, and AFAICT the only way to view the server-seed hash is via a network request to "/ajax/modal" with "modal=fairness".

So this means they can actually if you're verifying the bets or not. So they could trivially cheat only when they know you won't be able to tell (when you never requested the server-seed hash).

---

So I'm going to agree with the OP on this one: the site doesn't meet standards expected of a provably fair site.

Obviously..


It doesn't matter if it's public, it's exclusively picked by and controlled by the server (which knows the unhashed server-seed). Your website description of a client seed is correct, and the the very name "client seed" makes it clear that it's a seed set by the client after seeing the hashed server seed. Yet your site doesn't work that way.   It can be done automatically (via client side random generation) but it should be set by the client, and absolutely must be allowing user input.


As it stand, the site clearly doesn't meet the standard threshold of "provably fair" and is imho engaging in pretty deceptive conduct by trying to explain away a major problem with technobabble.


---

Put another way, if you simply removed the "client seed" the player would have exactly the same guarantees -- which just makes the whole client-seed as implemented by your site purely smoke-and-mirrors.

I was asked to comment on the provably fairness of this site.

AFAICT it doesn't even pass a cursory glance. I wasn't even able to specify my own client seed. Even the "refresh" option would generate a new one, server-side (where the server seed is known).

I'm not quite sure how the name "client seed" isn't a dead-giveaway that it should be picked by the client. I don't want to imply malice, but it's odd the site explanation directly contradicts how it actually works:

Honestly, browsers (and ICANN) have really dropped the ball. The amount of homograph domain attacks I've seen is absolutely absurd to the point of turning the URL bar virtually useless. I've almost been phished myself by a site, whose domain rendered virtually perfectly -- the only way I realized something was amiss was my password manager was not filling the result. Literally the only way to see the domain wasn't what i was expecting, was running it through a unicode decoder.

And another common attack-vector is enabled by Google being almost (?) semi-complicit by allowing people to bid for ads for $BRANDNAME when it's clear people are just googling (often via url bar) for $BRANDNAME

And of course it's also sad that passwordless logins have not got more traction -- as I think the whole idea of a password as a shared secret is just fundamentally bad.


But yeah, there's also some shit you just can't sanely prevent -- like people tricked into running malware

Seems unlikely. Bustadice is quoting me 2531 satoshis for an instant withdrawal (although that amount is constantly changing), while the amount missing is 143023 satoshis, which to me seems way too high to chalk off as fees.
Assuming everything in your story is as described, it could give interesting insight. I would try chase up exactly what happened. We have a few possibilities if your account was compromised:

a) They gambled the $10, then decided with withdraw the rest.

If so, why were they not worried about getting noticed?


b) They withdrew everything but $10, which they left to gamble.

If so, this seems to indicate they are a compulsive gambler, or something?


c) They were sloppy and just threw away $10?  

If so, weird. The withdrawal form has a "max" (and iirc default to it).




I would be careful to not try do your own blockchain analysis, it's quite a bit more subtle than you imagine. Just report the direct address you were given (even though it currently has 0 balance), if you didn't withdraw there -- and let the experts try track where it flowed to.

I think the "paid by a competitor to post lies" is something that seems logical, but in my estimation pretty much never happens. I'm not exactly sure why, but if I had to guess, the competitors that would ostensibly benefit the most are in that position because they've worked hard on building a trustworthy brand and focused on making a good product.  Plus a bunch of FUD around bitcoin-casinos could likely indirectly harm them more than what they'd directly gain.



Ok. So that's interesting. So it means the withdrawal happened:

2019-12-10 14:36

And the deposit you linked to earlier would've confirmed at:

2019-12-10 14:34

---

So basically within 2 minutes of the funds hitting your account, they were withdrawn. You also mention your account was deleted, which requires a passwords. So my money is strongly on someone else must have had your account/password?

You could also probably consider contacting chainalysis.com, and asking them to flag that address. They work with a lot of exchanges, and it's possible it'll help lead to the recover of your funds if they are deposited to an exchange or something like that


--

Edit: Did Daniel actually give your that address? Or did you just find it on a block-explorer? Because it doesn't really add-up to me. You deposited 0.14 BTC, but then 0.13856977 BTC was immediately sent to that address.  So there's about ~$10 missing. If it was a compromised account, why wouldn't they take the entire balance of the account? It would be odd for them to gamble on a compromised account (as the real owner would likely notice) and it would be odd to not hit "max" on the withdrawal form.

I suspect the point is that Dean wants a place to try link to and make people think there's a slight chance he's working on paying back people. It's a nice strategy to try stall people from taking (legal) action against him. He's even gone as far as to extort people saying that any talking bad of him, or taking any legal recourse against will result in them being not paid back. I think the play here is just that if you can stall people, after a few months they're far less angry about it and far less likely to actually do something.

It's actually pretty much common of scammers to try placate their victims after the fact. I'd say it easily happens 90%+ of the time. I remember when dice.ninja went dark they deleted absolutely all their accounts everywhere and everything, but still left signed-messages from their cold-storage address promising that people would get paid back (which of course never happened).

Oh, rofl. I completely forgot about the history tab. >< Yeah, then just switching to the history tab seems like the obvious solution for anyone who wants to not look at the chat 

I think kprawn makes a reasonable point about the chat frequently being pretty bad. What about adding the ability to leave all chat-channels and then the UI just hides the chat completely (except a button to re-enable the chat)?

Well precisely because it's provably fair, you can prove the bust points aren't reacting to players bets. However, it still would be possible for players to be reacting to the game bust (i.e. they might know effectively know the server-seed). If that was the case, though, you'd probably expect to see the opposite (players betting on high busts).

That said, in v2 players have bet 486,760 BTC and the return-to-player has been 481,827 BTC or 98.986% . ... which is extraordinarily close to 99%, which is the expected value due to the house edge. So I doubt there's anything strange going on, with the most likely explanation is just something like confirmation bias 

I don't think that's quite correct. That user will be auto-cashed out at 1.67x or what ever, but not the game itself. The game itself has a separate higher limit. Hence for the game limit to be hit, you generally require >= 2 whales playing at once (or it happens at a very high bust point).

And ideally, the per-game limit never gets triggered, because it's rather shitty for players that their bets are affected by other players action (even though it doesn't change the EV, it still sucks)

Maybe take a look at p2pool, which kind of allows you to get paid for mining almost-blocks.

While of course anything is possible, I think it would be a huge mistake to try conflate mining and transactions in a proof-of-work system, as the people making transactions are not going to be in a position to contribute more than a negligible amount of hash power (better to just pay for that hash power, via fees).