Theory for 1,000bets per second dice

[tortic25]

I'm not to experienced with this stuff just thought it might work and would like to hear others opinion.



Update
1. website for account management this would show the users balance and allow users to change their client seed at anytime.

2. gui "this is where the user would setup their bot settings to run bets and watch the results. this part would be important because the user would be screen sharing to a vmachine "same cloud service" so all the provably fair data "client side" would use a local network for faster processing.

if the vmachines where hosted by the casino there would probably be concern with the fairness which would be the biggest issue. maybe need a 3rd party and "everyone rent there own" via the same service the casino is using.


but forget about finding a solution for fairness atm. if the data was handled this way would it be possible for these services to offer 1,000bets per second


here is a image i made explaining it
https://imgur.com/a/GCDAftH

[1715667081]

1715667081

[1715667081]

1715667081

[1715667081]

1715667081

[Don Pedro Dinero]

Not sure what you are talking about?

If you are talking about finding a flaw in the casino using that system it may work, although I doubt that is possible.

Otherwise, the more you bet, the more you are going to lose.

I've googled that and I haven't found anything as such (Theory for 1,000bets per second dice).

[Wendigo]

I don't quite follow you. Are you talking about the development of a new ground-breaking dice betting experience where players can roll 1000 times per second using cloud computing like Amazon servers? Or are you talking about speeding up your dice rolls on existing dice sites up to 1000 rolls per second? Your explanation is very spotty and confusing, sorry.

[tortic25]

I don't quite follow you. Are you talking about the development of a new ground-breaking dice betting experience where players can roll 1000 times per second using cloud computing like Amazon servers? Or are you talking about speeding up your dice rolls on existing dice sites up to 1000 rolls per second? Your explanation is very spotty and confusing, sorry.

the first one,
servers using cloud computing to handle the rolls on their end.  without the users having to send all the data to the server.



heres a more detailed version.


1. website for account management this would show the users balance and allow users to change their client seed at anytime.

2. gui "this is where the user would setup their bot settings to run bets and watch the results. this part would be important because the user would be screen sharing to a vmachine "same cloud service" so all the provably fair data "client side" would use a local network for faster processing.

if the vmachines where hosted by the casino there would probably be concern with the fairness which would be the biggest issue. maybe need a 3rd party and "everyone rent there own" via the same service the asino is using.


there's a few holes in "how it would be ran and fair"
i'm just wondering if all the data was handled this way could this speed be achieved,


btw someone posted the more you roll, the more you lose.
of course that is how all casino games work you lose in the end i'm not trying to find a full proof method for winning. and betting strategy's do offer a very small edge imo.  but its offtopic

and some other post asked if i was trying to find flaw in a casino. no

[avikz]

I don't really understand your plan here. I believe you are talking about autobet system which is available in all dice websites. You need to select your initial bet amount an then few conditions are given like if you would want to increase the bet amount after every win or not and so on. I don't really understand what is the need of the central cloud server to roll the bets! can you please elaborate in clear and concise way? Also I don't think any dice website will allow you to execute even 100 bets per second.

[eternalgloom]

If I'm understanding this correctly, you are proposing that dice websites add extra servers to handle more bets per second than they are able to handle now?
Not sure what you mean by screen sharing? I mean you'd just be connected to a different server, not sure where screen sharing comes in?

The thing is that this would be way too expensive, there's a reason why dice sites cap the amount of rolls per second per player. There's a point where you'd become unprofitable due to the added costs.

Or are you suggesting that the bets are done client-side, thus allowing for faster bets/second?

[tortic25]

I don't really understand your plan here. I believe you are talking about autobet system which is available in all dice websites. You need to select your initial bet amount an then few conditions are given like if you would want to increase the bet amount after every win or not and so on. I don't really understand what is the need of the central cloud server to roll the bets! can you please elaborate in clear and concise way? Also I don't think any dice website will allow you to execute even 100 bets per second.

no i'm not talking about autobets.

and you answered your own question

"what is the need of the central cloud server to roll the bets"

Also I don't think any dice website will allow you to execute even 100 bets per second.



they don't allow it because it uses too much resources.

imagine 1000 users playing rolling 100bets per second. they can't do it.

they would need to rent a cloud service to handle processing bets.


and the user would need a way to transfer this data so the bets get processed. ideally this would eliminate 95% of data being transferred.



i'm not sure how to be more clear about this. "and it's my fault idk how to put it into words.


i think everyone is getting caught up in the purpose more then the question.


the virtual machine will act as a middle man

instead of the normal way user sending data the the server then vice versa.
the user would send data to the vmachine with predefined settings then the vmachine would send data back and forth to the server. on a local network
removing almost all latency. "besides the bet history the user would be shown"
 

[tortic25]

If I'm understanding this correctly, you are proposing that dice websites add extra servers to handle more bets per second than they are able to handle now?
Not sure what you mean by screen sharing? I mean you'd just be connected to a different server, not sure where screen sharing comes in?

The thing is that this would be way too expensive, there's a reason why dice sites cap the amount of rolls per second per player. There's a point where you'd become unprofitable due to the added costs.

Or are you suggesting that the bets are done client-side, thus allowing for faster bets/second?

i think you answered my question  

"I mean you'd just be connected to a different server, not sure where screen sharing comes in"
thats my point if you connect to a server hosted by the same cloud service the autobetting would be almost instant traveling from server to server... instead of traveling a long distance. i was thinking this would reduce alot of latency

i wasn't sure if dice sites could handle it or if they didn't have enough bandwidth to. so it wouldn't be worth doing.

[mostkey]

it seems that many here do not understand what you are talking about. and I also do not understand with what you mean .. it looks like you have to fix the OP so we can better understand what you mean

[devans]

Eliminating delays between bets can be accomplished without requiring users to maintain a virtual machine close to the game server. Conceivably, the casino could allow the user to submit his script which will be run by the casino's server itself.

Or, as a simpler case, the casino could allow users to specify how many bets they want to place. So for example, instead of saying "place a 1 BTC bet at 2x" to the server the client could say "place 1,000 bets of 1 BTC at 2x" and the server would then process those bets as quickly and as far as possible.

In either case the game will still be provably fair assuming the script's behavior is deterministic.