Search content
Sort by
Showing 16 of 16 results by husseinhere
Something happened with the actuallyfair.com ?
Sorry about that, there's a problem with actuallyfair where it's having some networking issue when connecting to the server that is privately hosted for bustabit. I have a permeant fix for that, and plan on deploying it today in a few hours
As it has a proven track record it is unlikely for any issue to arise on the Bustabit server therefore third-party associates would most probably be where to look. If any outage were to happen at ActuallyFair (correct me if I am wrong) it would bring a cloud of uncertainty to all rounds that have finished on Bustabit until the connection was re-established.
Before bustabit accepts any bets to a round, it connects to ActuallyFair and collects the piece of information it needs to calculate a game result (the bust point). Only then does the round open for bets. So should ActuallyFair not be available, bustabit would be paused until it's able to connect. If it was done in a different way (e.g. Bustabit could start without ActuallyFair) it would open the possibility of cheating (i.e. bustabit pretends it couldn't connect to ActuallyFair because it didn't like the roll outcome).
All that said, ActuallyFair has been specifically designed to be highly available. Customers are provisioned with their own dedicated instance, which is firewalled so only the customer can connect to it (i.e. making it immune to DDoS attacks and the like) , and it has automatic fallback in a different physical location. So I hope to not have to eat my words, but availability should be very, very good.
4. You mentioned the addition of a third party auditor, is that not redundant if the player can follow the hash chain and see crash results locally for themselves? What is the purpose of that addition?
I'll be acting as the third party, so perhaps I can speak to this. What devans wrote above is a great answer. But to add a bit more context, the main benefit of a third party auditor is actually for bustadice. On Bustadice ActuallyFair will be able to provide a significant amount of guarantees, this is because ActuallyFair is given and records all the bet information before the outcome is provided to bustadice. However in bustabit this is not possible because players are able to cashout after bustabit knows the crash point.
So more practically ActuallyFair was used to provide a lot of value to Bustadice, and it sort of just makes sense to use the same system for both even though the benefits to Bustabit are more minor.
Re: ActuallyFair.com :: Provably fair, augmented by a third-party
We have rebranded from provablyhonest.com to actuallyfair.com -- however everything will continue to function normal, and all old URLs and services will operate as usual.
so the house edge is still 1%?
Yeah, you are able to verify this by analyzing the by the "gameResult" function
Also quoting to show the post hasn't been edited, and confirming bitcoin block 831500 has not yet been mined.
Welcome to bustabit's third provably fair seeding event.
Our provably fair system, based on the first seeding event, is evolving into an advanced multi-party provably fair scheme. We have integrated ActuallyFair.com's Vx, a third-party service contributing to the algorithm that converts game hashes to game results. This not only helps us have a more secure system, but also preserves all provably fair guarantees while allowing Actually Fair to verify all games on behalf of our players.
1. Starting with a secret, we have generated a chain of 100,000,000 sha256 hashes by recursively hashing the binary value of the previous hash. Every hash in the chain will be used to generate a game result. The first element in the chain is the hash of game #100,000,000 and the last one is the hash of game #1, aka our terminating hash, which is: 567a98370fb7545137ddb53687723cf0b8a1f5e93b1f76f4a1da29416930fa59.
You can verify if a hash is part of the chain with a function like this:
Which could be used like:
2. Vx will use its BLS public key: b40c94495f6e6e73619aeb54ec2fc84c5333f7a88ace82923946fc5b6c8635b08f9130888dd96e1 749a1d5aab00020e4.
3. We will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point in a provably fair manner.
4. To prove that Actually Fair and bustabit have picked a fair hash chain (and public key) we will also mix in the lowercase, hexadecimal representation of the hash of a Bitcoin block that has not been mined yet: Bitcoin block 831500. This will be known as our game salt.
5. Vx gives us a signature (vxSignature) by signing the concatenation of the previous game hash along with the game salt. Vx uses BLS signatures so that it is not possible to generate multiple valid signatures for a particular message. We can validate the signature with something like:
5. Once we have a valid vxSignature, we take the next unused hash from the chain and use it to determine game results:
For more reference code, take a look at our open-source verifier and at this illustrative demo.
Our provably fair system, based on the first seeding event, is evolving into an advanced multi-party provably fair scheme. We have integrated ActuallyFair.com's Vx, a third-party service contributing to the algorithm that converts game hashes to game results. This not only helps us have a more secure system, but also preserves all provably fair guarantees while allowing Actually Fair to verify all games on behalf of our players.
1. Starting with a secret, we have generated a chain of 100,000,000 sha256 hashes by recursively hashing the binary value of the previous hash. Every hash in the chain will be used to generate a game result. The first element in the chain is the hash of game #100,000,000 and the last one is the hash of game #1, aka our terminating hash, which is: 567a98370fb7545137ddb53687723cf0b8a1f5e93b1f76f4a1da29416930fa59.
You can verify if a hash is part of the chain with a function like this:
Code:
import { sha256 } from "@noble/hashes/sha256";
import { bytesToHex, hexToBytes } from "@noble/hashes/utils";
const TERMINATING_HASH = "567a98370fb7545137ddb53687723cf0b8a1f5e93b1f76f4a1da29416930fa59";
function verifyInChain(hash: Uint8Array) {
for (let gameId = 1; gameId < 100e6; gameId++) {
hash = sha256(hash);
if (bytesToHex(hash) === TERMINATING_HASH) {
console.log("hash is in the chain. It is game: ", gameId);
return gameId;
}
}
console.error("hash is not in the chain");
}
import { bytesToHex, hexToBytes } from "@noble/hashes/utils";
const TERMINATING_HASH = "567a98370fb7545137ddb53687723cf0b8a1f5e93b1f76f4a1da29416930fa59";
function verifyInChain(hash: Uint8Array) {
for (let gameId = 1; gameId < 100e6; gameId++) {
hash = sha256(hash);
if (bytesToHex(hash) === TERMINATING_HASH) {
console.log("hash is in the chain. It is game: ", gameId);
return gameId;
}
}
console.error("hash is not in the chain");
}
Which could be used like:
Code:
verifyInChain(
hexToBytes("70eed5c29bde5132f4e41ec8b117a31533e5b055c6c21174d932b377a1855a04")
);
hexToBytes("70eed5c29bde5132f4e41ec8b117a31533e5b055c6c21174d932b377a1855a04")
);
2. Vx will use its BLS public key: b40c94495f6e6e73619aeb54ec2fc84c5333f7a88ace82923946fc5b6c8635b08f9130888dd96e1 749a1d5aab00020e4.
3. We will play through that chain of hashes, in reverse order, and use the hashes to determine the crash point in a provably fair manner.
4. To prove that Actually Fair and bustabit have picked a fair hash chain (and public key) we will also mix in the lowercase, hexadecimal representation of the hash of a Bitcoin block that has not been mined yet: Bitcoin block 831500. This will be known as our game salt.
5. Vx gives us a signature (vxSignature) by signing the concatenation of the previous game hash along with the game salt. Vx uses BLS signatures so that it is not possible to generate multiple valid signatures for a particular message. We can validate the signature with something like:
Code:
import { bls12_381 as bls } from "@noble/curves/bls12-381";
import { concatBytes, utf8ToBytes } from "@noble/hashes/utils";
const VX_PUBKEY = "b40c94495f6e6e73619aeb54ec2fc84c5333f7a88ace82923946fc5b6c8635b08f9130888dd96e1749a1d5aab00020e4";
function validateSignature(
gameSalt: string, // the hash of block 831500
prevGameHash: Uint8Array,
vxSignature: Uint8Array
) {
const message = concatBytes(prevGameHash, utf8ToBytes(gameSalt));
return bls.verify(vxSignature, message, VX_PUBKEY);
}
import { concatBytes, utf8ToBytes } from "@noble/hashes/utils";
const VX_PUBKEY = "b40c94495f6e6e73619aeb54ec2fc84c5333f7a88ace82923946fc5b6c8635b08f9130888dd96e1749a1d5aab00020e4";
function validateSignature(
gameSalt: string, // the hash of block 831500
prevGameHash: Uint8Array,
vxSignature: Uint8Array
) {
const message = concatBytes(prevGameHash, utf8ToBytes(gameSalt));
return bls.verify(vxSignature, message, VX_PUBKEY);
}
5. Once we have a valid vxSignature, we take the next unused hash from the chain and use it to determine game results:
Code:
import { hmac } from "@noble/hashes/hmac";
import { sha256 } from "@noble/hashes/sha256";
import { bytesToHex } from "@noble/hashes/utils";
export function gameResult(vxSignature: Uint8Array, gameHash: Uint8Array) {
const nBits = 52; // number of most significant bits to use
// 1. HMAC_SHA256(key=signature, message=hash)
const hash = bytesToHex(hmac(sha256, vxSignature, gameHash));
// 2. r = 52 most significant bits
const seed = hash.slice(0, nBits / 4);
const r = Number.parseInt(seed, 16);
// 3. X = r / 2^52
let X = r / Math.pow(2, nBits); // uniformly distributed in [0; 1)
// 4. X = 99 / (1 - X)
X = 99 / (1 - X); // 1 - X so there's no chance of div-by-zero
// 5. return max(trunc(X), 100)
const result = Math.floor(X);
return Math.max(1, result / 100);
}
import { sha256 } from "@noble/hashes/sha256";
import { bytesToHex } from "@noble/hashes/utils";
export function gameResult(vxSignature: Uint8Array, gameHash: Uint8Array) {
const nBits = 52; // number of most significant bits to use
// 1. HMAC_SHA256(key=signature, message=hash)
const hash = bytesToHex(hmac(sha256, vxSignature, gameHash));
// 2. r = 52 most significant bits
const seed = hash.slice(0, nBits / 4);
const r = Number.parseInt(seed, 16);
// 3. X = r / 2^52
let X = r / Math.pow(2, nBits); // uniformly distributed in [0; 1)
// 4. X = 99 / (1 - X)
X = 99 / (1 - X); // 1 - X so there's no chance of div-by-zero
// 5. return max(trunc(X), 100)
const result = Math.floor(X);
return Math.max(1, result / 100);
}
For more reference code, take a look at our open-source verifier and at this illustrative demo.
Thanks for chiming in. Your explanation about the "trilemma" that the system you have set up solves makes completely sense.
May you please explain a bit more in details PH offer more guaranteee to dice game ( what do you mean by atomic?) than crash?
May you please explain a bit more in details PH offer more guaranteee to dice game ( what do you mean by atomic?) than crash?
Just to avoid side-tracking this thread with stuff about ProvablyHonest, I replied on my PH thread: https://bitcointalk.org/index.php?topic=5457142.msg62734550#msg62734550
Re: ProvablyHonest.com :: Provably fair, augmented by a third-party
⭐ Merited by hopenotlate (1)
Thanks for chiming in. Your explanation about the "trilemma" that the system you have set up solves makes completely sense.
May you please explain a bit more in details PH offer more guaranteee to dice game ( what do you mean by atomic?) than crash?
May you please explain a bit more in details PH offer more guaranteee to dice game ( what do you mean by atomic?) than crash?
Crash is actually quite a difficult to do well, because it's a "realtime" game, latency really matters. And because it's multiplayer, you have to keep progressing the game for everyone.
There's a demo here of how to do crash with ProvablyHonest ( https://github.com/provablyhonest/vx-demo/blob/master/crash.ts ) but basically the casino simply "finds out" what the bust is at the *start* of the game (in a way that is provably fair, and wouldn't allow PH to cheat). Then the crash game happens, and then casino reveals the information to PH to show they computed the outcome correctly.
So the main advantage here, is from the casinos point of view: They don't need to worry as much about storing a highly secret "master seed" that if ever was leaked/looked-at would compromise all their games. They only find out the outcome just at the start of the game. But they still need to keep that a secret during the actual game. It would be trivial for the casino to have a bug which leaked the crash-outcome during the game. And this bug could be maliciously entered by a hacker / compromised-employee / backdoor etc.
A more atomic game, like dice, however ProvablyHonest does a much better job at. (code eg. https://github.com/provablyhonest/vx-demo/blob/master/dice.ts ). That is because the casino sends all the bet information (who is betting, how much they're betting, what they're betting on) to PH first and then it gets the outcome. Then it verifies the outcome (to make sure PH is not cheating). This is a much "nicer" design, because the casino never has a secret they need to store. They can't accidentally leak anything, because they never know it. Even if their software was compromised, the attacker can't really do anything that's not detectible.
⭐ Merited by hopenotlate (1)
if I get them correctly, they launched just recently (just 12 days after the creation of your account here, likely just a coincidence) : are you affiliated in some way with their business? And are you aware of other gambling sites using their services?
Asking because not having am IT background am not able to properly read their API documentations by myself and am just trying to get a general idea.
Asking because not having am IT background am not able to properly read their API documentations by myself and am just trying to get a general idea.
Hi hopenotlate,
To answer your question directly, I am dealing with MoneyPot at arms-length. And there are other casinos who are testing out ProvablyHonest services, but likely will not launch with it for at least another 6 months. ProvablyHonest has been in development for quite a long time, just the domain was to launch under was only recently resolved.
And to answer your question more practically: You should assume that MoneyPot and ProvablyHonest are the same entity and conspiring. You should assume we are have a strong relationship and abusing it. The entire system was actually built upon the premise:
MoneyPot should assume that ProvablyHonest and the player are conspiring. [So all outcomes it can verify itself, based on this]
Players should assume that MoneyPot and ProvablyHonest are conspiring. [All provably fair guarantees remain!]
ProvablyHonest should assume that MoneyPot and players are conspiring [e.g. it's playing on it's own site]
Even under this "worst case" assumption, the guarantees are identical to any other provably fair casino. But if the assumption is not correct, then there's additional security and verifications guarantees. But the really important point I want to stress is that there's no reason you should or need to believe they are separate entities.
FWIW the "additional guarantees" that ProvablyHonest offers are actually pretty minor in crash. ProvablyHonest works much better for an atomic game like "dice". Really the main winner here is actually just MoneyPot not needing to store a long-lived secret that if seen would compromise all future games and lead to the site easily be abused.
Re: Crash game fairness verification and salt decision notification
Hello world,
We are about to launch our own Crash game. In order to provide an absolutely fair game, we will now announce the formula for fairness verification and how to determine the salt:
We are about to launch our own Crash game. In order to provide an absolutely fair game, we will now announce the formula for fairness verification and how to determine the salt:
Hey TopGame,
seoincorporation is correct. You're fairly picking a salt, but by itself this does nothing because you haven't proved the other input to gameResult function is fairly picked.
Presumably you're using bustabit's method of provably fair. But what they do is first commit to a hashchain, and then prove the hashchain was not unfairly picked. You can see their seeding event:
https://bitcointalk.org/index.php?topic=922898.0 which you should use as a template
--
Also if you're interested in collaborating, I would be happy to help you setup a slight improvement over that with provablyhonest.com. You can see a casino that recently launched using it, here's there seeding event: https://bitcointalk.org/index.php?topic=5459744.0
It is significantly more complicated, but provides some additional guarantees. Specifically in the case of crash, it helps prevent the casino needing to store a long lived "top secret" that can derive all future games, making it much easier and safer to run a casino
⭐ Merited by coin-investor (1)
In conclusion the house edge in roobet is between 5% and 6%. Closer 5% if you are targeting low multipliers and closer to 6% if you are targeting high multipliers. It's not clear if this is intentional or an artifact of the bustabit v1 code that was copied to generate the game outcomes. Incidentally bustabit currently offers a flat 1% house edge, making it a strictly more economically better place to gamble. And the new moneypot.com offers crash in a very bustabit v1 style odds, with a house edge starting at only 0.1% (but based on a much more complex formula involving the casinos bankroll).
Re: ⭐ TronFun | Roulette&Duels | Provably Fair/Social Games | Fast Dep/With BTC-TRX
round duration 30 seconds. Look at the time of the previous round and add +30 seconds. simple.
If you check the provably fair section, the round is always finish every 30 seconds and the time is written.
If you check the provably fair section, the round is always finish every 30 seconds and the time is written.
Ok, that's good. But you need to include that information in your provably fair section and verification. That way if the round duration is not 30 seconds, someone can tell the round is not fair.
But your system is still has issues. For instance now the "ROUND_CREATED" and "SECRET" are values created by you, and as soon as you create those values you know the game outcome, thus you grind it to pick what ever outcome you want.
The standard solution would be a simply hash chain, popularized by bustabit ( https://bitcointalk.org/index.php?topic=2807542.0 ) or more novel approach would be using https://provablyhonest.com/ 's hashchain which would be able to offer you some extra guarantees against software errors or compromises
Re: ⭐ TronFun | Roulette&Duels | Provably Fair/Social Games | Fast Dep/With BTC-TRX
Quote
what you say makes no sense. I don't understand , Why should we make the result 1 second early or late?
Let's use your provably fair demo:
Code:
const ROUND_CREATED = "6/20/2023, 10:31:12 PM"; // Timestamp when round was created.
const ROUND_HASH = md5(ROUND_CREATED); // MD5 of Timestamp.
const SECRET = "vo1Ee1o11CSv"; // A 12-characters string randomly generated.
const ROUND_ENDED = "6/20/2023, 10:31:32 PM"; // Timestamp when round has ended.
const GEN_OUTCOME = hexdec(sha256(`${ROUND_HASH}-${SECRET}-${ROUND_ENDED}`).substr(0, 8)) % 15;
console.log("Outcome is", GEN_OUTCOME);
[/quote]
That prints: [code]Outcome is 2
const ROUND_HASH = md5(ROUND_CREATED); // MD5 of Timestamp.
const SECRET = "vo1Ee1o11CSv"; // A 12-characters string randomly generated.
const ROUND_ENDED = "6/20/2023, 10:31:32 PM"; // Timestamp when round has ended.
const GEN_OUTCOME = hexdec(sha256(`${ROUND_HASH}-${SECRET}-${ROUND_ENDED}`).substr(0, 8)) % 15;
console.log("Outcome is", GEN_OUTCOME);
[/quote]
That prints: [code]Outcome is 2
But let's say the round ended 1 second earlier (i.e. const ROUND_ENDED = "6/20/2023, 10:31:31 PM"; )
it would print:
Code:
Outcome is 13
Because we have no way of verifying when the round should have ended (or started!) there's no way to know if you have manipulated the result (or not).
A malicious site operator could easily cheat by picking secrets, start or end times to lead to what ever result they wanted. Therefor it's not provably fair =)[/code]
Re: ⭐ TronFun | Roulette&Duels | Provably Fair/Social Games | Fast Dep/With BTC-TRX
Congratulations on the launch. Unfortunately your provably fair system isn't actually provably fair. In fact, it's not even provably pre-determined 
Firstly, never use md5, it's been fully obsoleted for almost 15 years. You're already using sha256, so just stick to that. No need to mix in anything different. But the way you use it is very strange, you md5 the ROUND_CREATED ... for no purpose. And then don't md5 the ROUND_ENDED. You could actually just remove md5 with no functional difference.
But your fatal flaw is you have control of three variables SECRET, ROUND_CREATED and ROUND_ENDED which are timestamps. There's no way to validate that these values are picked fairly. The ROUND_ENDED is particularly insidious, because it would allow you to trivially cheat (i.e. make the round end 1 second later/earlier to prevent someone winning big).
If you are interested, I'm happy to help you integrate a best-in-class provably fair system and give you some demo code. I run https://provablyhonest.com/ and your roulette use case is well supported. Basically you'd use a hash-chain exactly like this: https://github.com/provablyhonest/vx-demo/blob/master/crash.ts#L75 and I'd make a custom roulette game type for you (which the outcome could be simply `vx_signature % 15` ). Anyway, if you're interested I'm happy to help. (And besides creating a robust provably fair system, my scheme would also help provide additional security guarantees)
Firstly, never use md5, it's been fully obsoleted for almost 15 years. You're already using sha256, so just stick to that. No need to mix in anything different. But the way you use it is very strange, you md5 the ROUND_CREATED ... for no purpose. And then don't md5 the ROUND_ENDED. You could actually just remove md5 with no functional difference.
But your fatal flaw is you have control of three variables SECRET, ROUND_CREATED and ROUND_ENDED which are timestamps. There's no way to validate that these values are picked fairly. The ROUND_ENDED is particularly insidious, because it would allow you to trivially cheat (i.e. make the round end 1 second later/earlier to prevent someone winning big).
If you are interested, I'm happy to help you integrate a best-in-class provably fair system and give you some demo code. I run https://provablyhonest.com/ and your roulette use case is well supported. Basically you'd use a hash-chain exactly like this: https://github.com/provablyhonest/vx-demo/blob/master/crash.ts#L75 and I'd make a custom roulette game type for you (which the outcome could be simply `vx_signature % 15` ). Anyway, if you're interested I'm happy to help. (And besides creating a robust provably fair system, my scheme would also help provide additional security guarantees)
Re: ProvablyHonest.com :: Provably fair, augmented by a third-party
It's a Provably Fair Verifier.
Kind of. It's more of an alternative way of doing provably fair (while still being provably fair) that allows 3rd party auditing. It's unfortunately not compatible with existing provably fair systems, so it's not simply just a verification tool
ProvablyHonest.com :: Provably fair, augmented by a third-party
Today I'm happy to soft-launch a product I've been working on for quite a while.
The core service I have is quite robust, and ready for real production use. Before a hard-launch, I'd like to get in contact with any (new or existing) casinos who might be interested.
We have devised a clever little ceremony that allows us (a third party) to participate in a casinos provably fair game result generation. We call our service Vx (short for Verified-By). After careful design we ensure the following guarantees:
The Benefits to the Player
Under a standard provably fair system, if a player is cheated, the burden falls on them to validate their games meticulously—an often technical task that fewer than 1 in 10,000 players undertake. Furthermore, even if a player identifies cheating, they lack tangible evidence to present. Claims against casinos typically are baseless, which makes any legitimate complaint without evidence difficult to present. With the introduction of Provably Honest, players gain a third-party who can verify their games on their behalf, without compromising the players' ability to validate the games independently, should they question Provably Honest's credibility.
The Benefits to the Casino
Operating an online casino can be slightly terrifying. With so many possible exploit vectors, it's almost impossible to be totally confident in the security of your system. And to make matters worse, exploits can (and most often are) totally undetected/undetectable. Would a casino really notice if your cloud-hosting provider had a malicious employee that peeked at its server seed and proceded to carefully use it?
Our service, Vx, provided massive security benefits by actively contributing to game outcomes. Thus, even if the casino's security is entirely compromised, Vx maintains a record of its transactions. This allows casino owners to conduct independent audits and reconcile the findings with their actual revenue. This newfound insight provides unprecedented assurance. Never again question if a players win was legitimate or not. Know.
The Potential Challenges
The most notable drawback lies in the fact that Vx becomes an essential component in the casino's game betting pathway. This means that for every single bet, the casino must communicate with Vx. If Vx's service suffers from any delay or disruption, all bets will be affected correspondingly. This is something we take very seriously, and have put a huge amount of effort on. We have designed our system to shard, so we can offer every casino their own dedicated service that is hosted physically close to their servers.
For more information check us out at https://provablyhonest.com and don't hesitate to get in touch
The core service I have is quite robust, and ready for real production use. Before a hard-launch, I'd like to get in contact with any (new or existing) casinos who might be interested.
We have devised a clever little ceremony that allows us (a third party) to participate in a casinos provably fair game result generation. We call our service Vx (short for Verified-By). After careful design we ensure the following guarantees:
- The player is able to verify their games (all provably fair guarantees are preserved!)
- Vx is able to verify all games (immediately!)
- The casino does not need to trust a player (aka the status-quo)
- The casino does not need to trust Vx
- A player and Vx can not conspire to cheat the casino
- A player and the casino can not conspire to trick Vx
The Benefits to the Player
Under a standard provably fair system, if a player is cheated, the burden falls on them to validate their games meticulously—an often technical task that fewer than 1 in 10,000 players undertake. Furthermore, even if a player identifies cheating, they lack tangible evidence to present. Claims against casinos typically are baseless, which makes any legitimate complaint without evidence difficult to present. With the introduction of Provably Honest, players gain a third-party who can verify their games on their behalf, without compromising the players' ability to validate the games independently, should they question Provably Honest's credibility.
The Benefits to the Casino
Operating an online casino can be slightly terrifying. With so many possible exploit vectors, it's almost impossible to be totally confident in the security of your system. And to make matters worse, exploits can (and most often are) totally undetected/undetectable. Would a casino really notice if your cloud-hosting provider had a malicious employee that peeked at its server seed and proceded to carefully use it?
Our service, Vx, provided massive security benefits by actively contributing to game outcomes. Thus, even if the casino's security is entirely compromised, Vx maintains a record of its transactions. This allows casino owners to conduct independent audits and reconcile the findings with their actual revenue. This newfound insight provides unprecedented assurance. Never again question if a players win was legitimate or not. Know.
The Potential Challenges
The most notable drawback lies in the fact that Vx becomes an essential component in the casino's game betting pathway. This means that for every single bet, the casino must communicate with Vx. If Vx's service suffers from any delay or disruption, all bets will be affected correspondingly. This is something we take very seriously, and have put a huge amount of effort on. We have designed our system to shard, so we can offer every casino their own dedicated service that is hosted physically close to their servers.
For more information check us out at https://provablyhonest.com and don't hesitate to get in touch