Topic: Let's create a new system for provable fairness. (Read 545 times)
the only way a site will be truly provably fair is that player can have access to the game panel. but we all know that cant happen, is now up to people can trust the ops. I beleve games that you play against the owner are more likley to be rigged. Then PVP games
I know it's a long shot but every site should implement the same system to join the "league of trust".
The code should be open source and deal with the current problems you stated.
Websites failing to implement this new system would not be trusted.
I'm not familiar myself with all the technical possibilities though.
The code should be open source and deal with the current problems you stated.
Websites failing to implement this new system would not be trusted.
I'm not familiar myself with all the technical possibilities though.
It would benefit the community if we all collaborated to make a new system. We should start off by listing problems with current provably fair systems.
We can add more if you post them here.
We should also list possible solutions to these problems. What if when a user signed on to a site, they input a deterministic wallet chain code. The site now locks that in to the account, and the user cannot have coins stolen because the site can always send to an address from that wallet and the client will have it. This also eliminates another problem.
As for the client seed, every roll could use the next deterministic address as the client seed. The site does not need to have the private keys, but if they have an address and a chain code, they can create all the next addresses, but not private keys.
I should not be the only person with input here. If you have ideas, post them. I'm just trying to get the ball rolling.
- The need to change a user seed every time in some cases.
- Using variables in the hash that cannot be verified by the user that they were not changed after the bet. (Time, etc.)
We can add more if you post them here.
We should also list possible solutions to these problems. What if when a user signed on to a site, they input a deterministic wallet chain code. The site now locks that in to the account, and the user cannot have coins stolen because the site can always send to an address from that wallet and the client will have it. This also eliminates another problem.
As for the client seed, every roll could use the next deterministic address as the client seed. The site does not need to have the private keys, but if they have an address and a chain code, they can create all the next addresses, but not private keys.
I should not be the only person with input here. If you have ideas, post them. I'm just trying to get the ball rolling.
Tbh, i dont think 100% foolproof provably fair is even possible, there is always room for manipulation, im not saying gambling sites do manipulate rolls but they can .
They dont need to do it , in long term its better to be fair and u will get rewarded with players and profit .
When i come up with some ideas for better provably fair i will come back and post my thoughts .
It would benefit the community if we all collaborated to make a new system. We should start off by listing problems with current provably fair systems.
We can add more if you post them here.
We should also list possible solutions to these problems. What if when a user signed on to a site, they input a deterministic wallet chain code. The site now locks that in to the account, and the user cannot have coins stolen because the site can always send to an address from that wallet and the client will have it. This also eliminates another problem.
As for the client seed, every roll could use the next deterministic address as the client seed. The site does not need to have the private keys, but if they have an address and a chain code, they can create all the next addresses, but not private keys.
I should not be the only person with input here. If you have ideas, post them. I'm just trying to get the ball rolling.
- The need to change a user seed every time in some cases.
- Using variables in the hash that cannot be verified by the user that they were not changed after the bet. (Time, etc.)
We can add more if you post them here.
We should also list possible solutions to these problems. What if when a user signed on to a site, they input a deterministic wallet chain code. The site now locks that in to the account, and the user cannot have coins stolen because the site can always send to an address from that wallet and the client will have it. This also eliminates another problem.
As for the client seed, every roll could use the next deterministic address as the client seed. The site does not need to have the private keys, but if they have an address and a chain code, they can create all the next addresses, but not private keys.
I should not be the only person with input here. If you have ideas, post them. I'm just trying to get the ball rolling.
Jump to: