I think you must have a really bad connection or something because everything you are seeing no one else is.
I use a satellite connection. I have a ping time between 600 and 700ms to pretty much anywhere. That's pretty bad, but I like living in the middle of nowhere, so it's a compromise I'm happy to put up with. My laggy connection has helped several sites diagnose intermittent bugs in their code, because it tends to exacerbate race condition type errors.
Anyways lets try this you guys first didn't like our provable fair system because the house had the hash+salt meaning we knew the winning number every time just like Ryan at bustabit knows what its going to bust at every game.
You're misrepresenting things there. First off, I don't represent any group. I'm speaking for myself. So your characterisation of "you guys" isn't fair. It looks to me like lots of individuals can see the problems with your site and are pointing them out to you. There's no need to see it as an us-against-them situation. Just read what people are telling you, and try to think about whether they make sense of not. This isn't a war.
The reason I don't like your "provable fair" system is because it isn't provably fair. The house can play against the other players and guarantee to win every time. I'm not saying you do, but you could. And that is what stops it being provably fair.
Ryan's bustabit site is a completely different case. The players on bustabit aren't playing against each other. They are all playing against the house. So the fact that Ryan knows the crashpoint ahead of time doesn't help him much at all. The only problem I see with his system is that there is a per-round profit limit. He could theoretically play his own game to "use up" some of the maximum profit and cause other players to cash out early. But he can't make them lose like you can on your site.
Then we changed it to picking a hash from blockchain so no one knows the winning number until the game is over. But now you say we can broadcast to blockchain a tx id so we win.
Yes. You can broadcast transactions. Everybody can.
I don't know if you made that particular transaction. I'm not actually online at the moment and my local bitcoind tells me "Invalid or non-wallet transaction id" so I can't look at the details. But that's irrelevant. You could have made another transaction at the same time with a txid which made one of your tickets win, and you could have selected that transaction instead. I don't understand why you can't see that you could do this.
Lets end this talk about what we can do to cheat the system, and you the so called expert tell us exactly in detail how you want the system to be and we will change it to your system.
We only want to be provably fair, all the talk of us being able to cheat needs to stop, and it sounds like you can tell us how.
I don't have a clear idea of how the system should be. It's a tricky technical challenge to make a multiplayer game provably fair. Ryan's pevpot is the only place that I have seen even really attempt it (and maybe an old lottery run by Dabs, but I don't remember if he ever launched it or not).
Ryan's solution is to use a bitcoin block hash from after the game ends, and to use a key-stretching function with a lot of iterations to make it impossible for anyone to know who won until an hour or two after the block is found. That works for him because he only has one draw per week. It wouldn't work for you, because your games last less than a minute and people don't want to wait to see if they won or not.
You can't use the traditional "(server hash) -> (client seed) -> play -> (reveal server seed)" technique, because you have multiple players, some of whom could be the house in disguise.
You can't hash the house pick the randomness at the end (like picking a txid, a time in milliseconds, or anything else non-repeatable) because the house at that point has perfect knowledge and can pick the randomness to make their own player win.
But stealing from Ryan's idea, I think a reasonable scheme could be something like the following:
1) use some kind of client seed from each player (player's name + client-side random number, maybe?)
2) use "the last txid after 10 seconds", or any other server-generated randomness
3) hash those two together, then use a stretching function which takes 5 minutes to run to decide the winner
That way, you can't calculate which randomness to use in step 2 to win, because it takes 5 minutes, and you only have 10 seconds * number of ticket purchases at most (so maybe we need to use a longer stretching function when there are more tickets bought).
The key is that step 3 takes longer to run than the time you have available to pick the server-side randomness.
