ASLDicebot.java update

[derimmer]

I have received an update to this file that expands some of the dice report. It was shared on GS and received quite positive responses. I will add it to 6.6.4.

[derimmer]

Through VASL.info and follow up email we have received the comments below which seem to warrant some review. Anyone know anything about this?

Recently a friend of mine found out that VASL generates a batch of 1000 random d6 numbers during the initialization (either from VASSAL or random.org) and then uses them sequentially when the player pushes the DR button. So the player may get the list of all his future rolls before the game and even substitute them.

I know that VASL was made with the consideration that playing with any kind of cheating is meaningless nonsense, because random die roll results are the heart of the game and its hazard.

Nevertheless, when playing rating games or a tournament with unknown people one needs a formal guarantee that dice rolls are fair.

So, is it possible to implement in future versions of VASL a validated random die roll generation during the pressing DR button?

Next message:

Re dice rolls in VASL. Of course, I might be mistaken, but I believe all rolls are generated within ASLDiceBot class. There are a couple of ways to stack die rolls in the player's favor if we rely on this code. Generally, if we are talking about guaranteed fairness of the rolls, the approach when die roll is generated only on one side will never produce a fair result.

This problem is well known and the solution for this problem is long time adapted by various online gambling sites.

There are a couple of links that introduce the solution algorithms. https://keybase.io/blog/cryptographic-coin-flipping. https://dicesites.com/provably-fair

From the other side, I had a similar discussion with the developer of the "Last Hundred Yards" VASSAL module. In his opinion, we have to just wait. VASSAL is planning to release a new version of VASSAL with random generation (and verification) by the external service.

[zgrose]

Probably my prototype VASL dicebot which output the list for debugging/statistical purposes. No one ever followed up on the statistics though and it displays a message that the code was modified.

The test was to see if the secondary Random of the 1000 values pulled from random.org had any unintended side effects.

The rest seems to be the typical dicebot paranoia.

[zgrose]

Per the validation bit, I think they are on the wrong track unless they start signing the module files and doing a cross check that each version has the same signature.

[uckelman]

I had a look at ASLDiceBot just now and I did find a problem, but it's not what's mentioned above. You're calling nextFloat() and then multiplying to get random integers, which introduces modulo bias.

(Modulo bias: Suppose you're rolling a d6. nextFloat() is basically the same thing as getting 32 random bits, and 2^32 isn't divsible by 6. 2^32-4 is divisible by 6, though, which means that over the whole range you're short a 5 and a 6. This introduces a tiny bias toward 1-4: Out of 715 million rolls, you're expected to get one less 5 and one less 6 than you should.)

It's easy to fix this. Instead of

(int)((l_RND.nextFloat() * 6) + 1)

you should do

l_RND.nextInt(6) + 1

nextInt(n) gives you an integer in the range [0,n). All the calls where you're using nextFloat() to produce an integer should be replaced by calls to nextInt()

I have some more comments about the other things, but will post those later.

[uckelman]

From what I can see, the ASLDiceBot is creating blocks of 1000 random numbers. I suspect this is being done so as to make fewer calls to random.org when that's being used. I would definitely not do that when using the local RNG.

However, this doesn't cut either way with security---it's just as (in)secure no matter how you roll if the rolls are presented by the local client. Using random.org to produce the rolls but not make them known to all players when they happen gives up all the advantages of using a third-party roller.

[uckelman]

(Sorry, didn't meant to close this---I hit the wrong button.)

[uckelman]

The user talking about fairness really means security. Fairness is about the distribution of the rolls, and I have yet to see any evidence that the rolls deviate from a uniform distribution (other than the modulo bias problem noted above, which isn't statistically detectable at any reasonable sample size).

As for the links: Yes, you can generate random numbers without a trusted third party, but it requires a lot of communication. Yes, you can get random numbers from an untrusted third party and verify later that they were generated by the method they were claimed to be. Neither of these are applicable for offline play.

[jyoung14]

I am musing about whether the color-coding of "good/bad" rolls in the VASL dice statistic outputs contributes to dicebot paranoia? Forgive my long post, I'm explaining the argument to myself as I go, as I was never great at statistics and perhaps someone with much better knowledge (uckelman?) can supplement or correct me. And yes I know I have too much time on my hands (actually procrastinating about work).

The population of all possible 2d6 rolls has a triangular distribution with mean (mu) of 7.0 and standard deviation (sigma) of 2.4. Any sample of n rolls has a sample mean that tends towards mu, with a standard deviation of sample means (the "standard error" SE) equal to sigma / sqrt(n), i.e. for 100 rolls SE = 0.24. Sample means within 1 SE of mu comprise approximately 68% of results, so for 100 rolls you have an approximately 16% (1/6) chance of being "lucky" (mean lower than 7.0-0.24 = 6.76) and 1/6 chance of being "unlucky" (mean higher than 7.0+0.24 = 7.24). By coincidence (?) VASL uses an arbitrary cutoff of 0.25 for green and red color-coding (<= 6.75 green, >= 7.25 red), but regardless of number of rolls n.

Also the stats are color-coded not just for the overall set of rolls but for each roll category (to hit, morale checks etc) and in a given VASL session of 100 rolls, there might be some categories (e.g. close combat) with only say 6 rolls (which would give a SE = 0.99). Thus for your 6 CC rolls to be considered "lucky" or "unlucky" they should have a mean below 6.0 or above 8.0, but VASL will color them green or red at 6.75 and 7.25 and in reality you had a very good chance of being outside those two limits. What I've defined as "lucky" and "unlucky" is subjective, but a color-coding cutoff of 2.4/sqrt(n) where n is the number of rolls in any given category would be more scientifically meaningful than the current 0.25 across the board.

Is this something worth thinking about for the distant future? Cheers, John

[derimmer]

I personally would put no effort into this.

Whiners are gonna whine.

Almost all vasl session DR/dr numbers are way too small for the results to have statistical meaning.

The expanded dice results are a nice addition. And sufficient.

Just my opinion.

Sent from my iPhone

On Jun 22, 2022, at 11:55 PM, jyoung14 @.***> wrote:

 I am musing about whether the color-coding of "good/bad" rolls in the VASL dice statistic outputs contributes to dicebot paranoia? Forgive my long post, I'm explaining the argument to myself as I go, as I was never great at statistics and perhaps someone with much better knowledge (uckelman?) can supplement or correct me. And yes I know I have too much time on my hands (actually procrastinating about work).

The population of all possible 2d6 rolls has a triangular distribution with mean (mu) of 7.0 and standard deviation (sigma) of 2.4. Any sample of n rolls has a sample mean that tends towards mu, with a standard deviation of sample means (the "standard error" SE) equal to sigma / sqrt(n), i.e. for 100 rolls SE = 0.24. Sample means within 1 SE of mu comprise approximately 68% of results, so for 100 rolls you have an approximately 16% (1/6) chance of being "lucky" (mean lower than 7.0-0.24 = 6.76) and 1/6 chance of being "unlucky" (mean higher than 7.0+0.24 = 7.24). By coincidence (?) VASL uses an arbitrary cutoff of 0.25 for green and red color-coding (<= 6.75 green, >= 7.25 red), but regardless of number of rolls n.

Also the stats are color-coded not just for the overall set of rolls but for each roll category (to hit, morale checks etc) and in a given VASL session of 100 rolls, there might be some categories (e.g. close combat) with only say 6 rolls (which would give a SE = 0.99). Thus for your 6 CC rolls to be considered "lucky" or "unlucky" they should have a mean below 6.0 or above 8.0, but VASL will color them green or red at 6.75 and 7.25 and in reality you had a very good chance of being outside those two limits. What I've defined as "lucky" and "unlucky" is subjective, but a color-coding cutoff of 2.4/sqrt(n) where n is the number of rolls in any given category would be more scientifically meaningful than the current 0.25 across the board.

Is this something worth thinking about for the distant future? Cheers, John

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.

[uckelman]

What's the goal here?

[jyoung14]

No worries, thanks Doug, I appreciate your thoughts - you have a good insight into what the community wants, given all the requests you get :-).

[FredKors]

It's funny to see how things don't change, even after 10 years...

:-)

[MoriQuessir]

It's not about "dicebot fairness" or "dicebot" paranoia. It's about possibility to forge dice rolls even making it looks "signed" by random.org, because dice results generated in batches of 1000 and not validated by both players: https://www.youtube.com/watch?v=VbuswHABE0A

[derimmer]

I have been looking at the code in ASLDiceBot.java and it does appear to me that VASL goes at gets random die rolls in batches of 1000 (from either the VASSAL bot or random.org). It then uses the the ASLDiceBot.GetDieRoll() to randomly select from that list and then returns that die roll and removes the selected item from the list. Once all 1000 rolls have been used up, another batch of 1000 is created.

Here is the code:

`private int GetDieRoll() { int l_iSlot, l_iRet; Random l_RND = GetRandomizer();

    if (mar_iDereferencingIndex.size() == 0)
        ReadRolls();

    if (mar_iDereferencingIndex.size() > 0)
    {
        // scelgo casualmente quale numero tra 0 e m_PointersList.size
        l_iSlot = (int) (l_RND.nextFloat() * mar_iDereferencingIndex.size());

        // prendo il numero scelto
        l_iRet = mar_iRandomNumbers[mar_iDereferencingIndex.get(l_iSlot)];

        // lo rimuovo per renderlo inutilizzabile
        mar_iDereferencingIndex.remove(l_iSlot);

        // ritorno il valore
        return l_iRet;
    }

    return 0;
}`

Am I understanding the code correctly?

If so then my view is that this is a perfectly adequate approach. Yes, I understand that somebody could modify their particular version of VASL to "forge die rolls". But frankly, if you are willing to go to those lengths to cheat and have the skills to do so then you have already figured out that there are easier and better ways to cheat in VASL. Hacking concealment would be the most obvious.

I am inclined to close this issue.

But not before I make the change that @uckelman suggested. Because nobody likes modulo bias.

[zgrose]

Personally, randomly picking from a list of random numbers seems a waste of time but I have no horse in this race. :)