Topic: In which language top gambling sites are coded ? - page 4. (Read 12752 times)

I'm not trying to be a dick here, but I'd rather use the status-quo. If you're going to add so much complexity, you're going to need to add some advantages, which I can't see what they are?


Who cares? Computers are fast. A million shuffles in a second doesn't seem impossible to me. But anyway, if you can have many tries, even picking the best of 2 or 3 gives you a mind-boggling advantage.



This just gets worse. What happens if the player disconnects between sending the hash of the seed, and the seed to the server?

You're talking about super-users or "God mode" players. That's a problem with all poker sites. My scheme does not address that specifically. The shuffle is still going to be very difficult to dictate as it would require several "tries" to get the preferred cards in the least amount of time, by the time the players send their committed client seeds. This can be minimized or negated by the dealer first accepting only the hash of the client seed, until all players have committed, then accepting all the client seeds, then shuffling quickly, then dealing.

Although, in practice, this can all be done in under a second.

The scheme is not about trusting the other players, it's about knowing for sure that the deal or shuffle, with a certain level of confidence, is fair or provably fair, and not just because the site said so. The usual problems that plague poker sites will be dealt with differently.

I mean, where would you rather play? In a provably fair game? Or in a probably fair game? (investors and house not included.)

If the house cheats, they will be discovered eventually (Absolute Poker and Ultimate Bet, for example.)

I read your scheme, but I honestly don't understand the utility it provides? It only works if all N players trust all other players. If one of the players works for the house not only can they see all cards, he can dictate the outcome of the shuffle. If you already trust all the players in the game, it's probably extremely unlikely that you are worried about the house playing favorites..

It depends on what you consider provably fair, since poker has other factors involved; but yes, in my version that makes the shuffle and deal fair since all players have input on how the deck is randomized. The dealer or site knows it ,all, the players could collude, and someone can DDoS you, but that's true for most poker sites.

A server seed + combined client seed of all players currently participating in a round could make Poker provably fair?

Would that be my thread?
https://bitcointalk.org/index.php?topic=274068.0;all

I believe, it's been accomplished, I just never got players. If you want to try, get a buddy to play heads up against you, I'll deal. Basically, I wanted people to try it out for real, instead of all being theory. I've tested it (by myself) but you never know until you actually do it.

Hmm? I remember reading a thread where a few members were trying to accomplish it. I don't think it's been implemented ever?

And don't forget, you can make poker provably fair. Or almost.

My experience is

Almost 20 years commercial net and 1M+ visitors a day to sites I've done over the years

Last couple of months I've been involved in a few different poker room projects

One is live and it caters to very high stakes games, usually you have a table of big money at a set time so they hardly need anything major, but they got a dedicated server and run a major poker room script.

A table with 9 players doesn't even move the load

Right now SWC is probably the major house, they have 300 to 500 players online all day

They use use cloud flare

We use the same script on one of the poker projects, a differnt one on another

3 More rooms are set to launch soon but they will cater to the low end of poker

Just look at the rooms on SWC you will see 98% of the action is micro bit tables, something the first two projects wanted nothing to do with

Now the othe projects wants the type of action SWC has

All the projects use dedicated high memory servers, a couple are win based the other are linux

Linux rooms cost a ton

Win rooms are cheap

Right now it seems most btc related gaming is dice related, not sure about that, haven't done dice, my projects involve poker rooms and sports betting and some nice canned video sucker games

video gaming the house has rigged just like slots in a casino, you set the script to peel off the juice you want 2% to 5% usually

poker is all about a rake

sports betting is the hardest thing to do right IMO

so no high volume connections to speak of with these rooms and I don't consider the action at SWC being 300-500 a lot of action

Now the dice games have huge load, lots of people and that is where you need to worry about connections

Poker rooms are memory intensive scripts and there's cheapies as well as expensive scripts

All are memory hogs

sports books, well there's a ton of ways to do them, it's more on the way you want to handle it, and how you feed live lines into it

the few major OLSB's seem to have their own custom lines and not just major vegas dumps

dice is where you have load issues

right now I have no real interest in doing any dice stuff, the reason is it is done

high stakes poker and high stakes books that's wide open for btc development IMO

Do u hav experience in running a real gambling site ? If yes, can u plz tell us the concurrent connections it experiences on an average ? By concurrent connections here I mean the real time visitors shown by Google analytics.

a lot of high end scripts are compiled to protect the companies IP work

so they say what they use, but inside can have a hybrid of languages and often due if you actually get to the source

Interesting post. I didn't know node.js is so popular already for web apps  

If the site is coded in Java, can the use of Java threading solve the problem of real time update ?

OP updated as per latest data found in the thread...