The only people who say that backgammon sites are not rigged are employees of 247, BG and VIP. It is soooo obvious. Can almost predict the next throw by the computer. I can be 25 pips ahead and almost ready to begin bearing off, and the opponent will suddenly roll a double 6 for "catch up". I can have my opponent on the bar with only one opening and way to hit me, and think, " the only way out is for the roll to be a 6 - 1" and that's what happens. Wish I could stop being seduced into playing. Wish, and would pay subscription money, to play in an "honest" game.

glen moulder schrieb am Freitag, 18. August 2023 um 21:20:48 UTC+2:
> The only people who say that backgammon sites are not rigged are employees of 247, BG and VIP. It is soooo obvious. Can almost predict the next throw by the computer.
Would you bet on that under controlled conditions? Say you win if you predict 5 out of 10 and loose otherwise?

>I can be 25 pips ahead and almost ready to begin bearing off, and the opponent will suddenly roll a double 6 for "catch up".
O.k. that convices me. I never heard that happened in real life.

But it is you own fault. Do the same that your opponent did to get the good rolls (because that is the funny thing with BG, your bad roll is his good roll).

On August 18, 2023 at 3:01:11 PM UTC-6, Frank Berger wrote:

> glen moulder schrieb am 18. August 2023 um 21:20:48 UTC+2:

>> Can almost predict the next throw by the computer.

> Would you bet on that under controlled conditions?
> win if you predict 5 out of 10 and loose otherwise?

What kind of stupid bet is this..?

A better bet on predicting rolls would be whether
a specific roll will happen or not, i.e. "yes or no",
with the amount won or lost being based on the
actual odds of that roll happening.

For example, if he predicts that the next roll will be
61 (or 16) and bets $1 on it, he should win $17 if it
happens and lose $1 if it doesn't happen. Or on the
opposite, if he predicts that the next roll will not be
61 (and 16) and bets $1 on it, he should only win $1
if it happens and lose $17 if it doesn't happen.

Similarly, for predicting a double the odds should be
1 to 35; for predicting only one number odds should
be 1 to 5; etc.

In fact compound bets can be made, such as "I will
not roll a 5 or 6, (i.e. to escape a blot), and then my
opponent will roll a 2 or double 1's, (to hit me)", etc.
and the amounts won or lost will be based on the
actual compounded odds.

If you offer this to me under controlled conditions,
let's say against the "rigged" Gnu-Dung ;), I'll take it.

>> I can be 25 pips ahead and almost ready to begin
>> bearing off, and the opponent will suddenly roll a
>> double 6 for "catch up".

> O.k. that convices me. I never heard that happened
> in real life.

You keep making this "never in real life" comment all
the time, even when people don't necessarily imply it,
in order to score points against your own strawman
that you create by exaggerating.

A better argument would be "how often" in "real life"
vs on "online servers" or "bots".

You guys seem to have amassed huge amounts of
games of each kind to be able to look at them and
find the answers for all kinds of similar questions,
such as "how often does a human vs a bot rolls an
anti-joker immediately after a cube action", etc. but
instead of doing the work to put an end to it, you all
prefer to just blabber nonsense about it forever... :(

MK

On Friday, August 18, 2023 at 11:47:17 PM UTC+1, MK wrote:
> On August 18, 2023 at 3:01:11 PM UTC-6, Frank Berger wrote:
> > glen moulder schrieb am 18. August 2023 um 21:20:48 UTC+2:
>
> >> Can almost predict the next throw by the computer.
>
> > Would you bet on that under controlled conditions?
> > win if you predict 5 out of 10 and loose otherwise?
> What kind of stupid bet is this..?
>
> A better bet on predicting rolls would be whether
> a specific roll will happen or not, i.e. "yes or no",
> with the amount won or lost being based on the
> actual odds of that roll happening.
>
> For example, if he predicts that the next roll will be
> 61 (or 16) and bets $1 on it, he should win $17 if it
> happens and lose $1 if it doesn't happen. Or on the
> opposite, if he predicts that the next roll will not be
> 61 (and 16) and bets $1 on it, he should only win $1
> if it happens and lose $17 if it doesn't happen.
>
> Similarly, for predicting a double the odds should be
> 1 to 35; for predicting only one number odds should
> be 1 to 5; etc.
>
> In fact compound bets can be made, such as "I will
> not roll a 5 or 6, (i.e. to escape a blot), and then my
> opponent will roll a 2 or double 1's, (to hit me)", etc.
> and the amounts won or lost will be based on the
> actual compounded odds.
>
> If you offer this to me under controlled conditions,
> let's say against the "rigged" Gnu-Dung ;), I'll take it.
> >> I can be 25 pips ahead and almost ready to begin
> >> bearing off, and the opponent will suddenly roll a
> >> double 6 for "catch up".
>
> > O.k. that convices me. I never heard that happened
> > in real life.
> You keep making this "never in real life" comment all
> the time, even when people don't necessarily imply it,
> in order to score points against your own strawman
> that you create by exaggerating.
>
> A better argument would be "how often" in "real life"
> vs on "online servers" or "bots".
>
> You guys seem to have amassed huge amounts of
> games of each kind to be able to look at them and
> find the answers for all kinds of similar questions,
> such as "how often does a human vs a bot rolls an
> anti-joker immediately after a cube action", etc. but
> instead of doing the work to put an end to it, you all
> prefer to just blabber nonsense about it forever... :(
>
> MK

Just a few remarks.
1. I do believe MK makes some reasonable points, but
the argument is very well-worn.

2. I do believe the dice are random. For open-source
code, this can be checked. Random-number generation
is very well-known, and I don't see any motivation to
introduce non-random dice, and I don't see any evidence
of non-randomness.

3. The "never in real life" comment was sarcastic, as I read it.

Paul

On Friday, 18 August 2023 at 22:01:11 UTC+1, Frank Berger wrote:
> glen moulder schrieb am Freitag, 18. August 2023 um 21:20:48 UTC+2:
> > The only people who say that backgammon sites are not rigged are employees of 247, BG and VIP. It is soooo obvious. Can almost predict the next throw by the computer.
> Would you bet on that under controlled conditions? Say you win if you predict 5 out of 10 and loose otherwise?
> >I can be 25 pips ahead and almost ready to begin bearing off, and the opponent will suddenly roll a double 6 for "catch up".
> O.k. that convices me. I never heard that happened in real life.
>
> But it is you own fault. Do the same that your opponent did to get the good rolls (because that is the funny thing with BG, your bad roll is his good roll).

I genuinely wonder what your view is of a developer of a backgammon app who is challenged (and refuses to acquiesce) to (a) display the RNG seed in use for any given game and (b) give the user the option of playing a new game using that seed.

So, for the (real) app in question, it has a nasty habit of rolling lots of 6-5s in the end race where the user gets a lot of 2-1, 3-1, 1-1, 3-2 rolls.

Repeatedly.

I suspect he hasn't quite got the noise right in his cheaty bit of code (i.e only call it if a number between 1 and 10 is higher than 7).

If you can prove definitively that your app isn't cheating, why wouldn't you?

Tony The Welsh Twat schrieb am Samstag, 19. August 2023 um 18:06:57 UTC+2:

> So, for the (real) app in question, it has a nasty habit of rolling lots of 6-5s in the end race where the user gets a lot of 2-1, 3-1, 1-1, 3-2 rolls.
could you provide some data that can be analyzed, e.g. the bots average in running games is 8.7 compared to 7.2 in 473 rolls? Even better if you have recorded all rolls. Than one could do e.g. a phi-square test and get some data to talk about. Nasty habit isn't something one can judge.

> If you can prove definitively that your app isn't cheating, why wouldn't you?
Maybe he's simply p.o.d. of the complains. Maybe the app cheats (if the AI is abysmal that might be a last resort). Would be easier if there are some recorded matches.

But in most complains one never sees relevant data.....

On August 19, 2023 at 2:00:27 AM UTC-6, peps...@gmail.com wrote:

> Just a few remarks.
> 1. I do believe MK makes some reasonable
> points, but the argument is very well-worn.

Yes, unfortunately way too "well-worn" because
server operators and bot developers refuse to
implement just one or two simple features that
could finally satisfy the old-timer complainers
and quickly convince new-comer complainers.

> 2. I do believe the dice are random.

Once again, you are doing your part to wearing
out arguments that had already been rebutted,
by offering nothing more than your "beliefs"...

> For open-source code, this can be checked.

Of all servers and bots out there, only Noo-BG is
open-source. And even that by itself isn't enough
as a definitively convincing proof, because there
remain arguments such as that one's inability to
find the cheating code doesn't prove that it's not
there, that the code one is looking at may not be
the one used to compile the EXE, etc. What I mean
is that overwhelming majority of users out there
aren't programmers who have to take the word of
someone else whom they may not trust.

> Random-number generation is very well-known,

Some algorithms may be well-known but specific
algorithms used by servers and bots aren't known.

> and I don't see any motivation to introduce non-
> random dice,

Good joke... :)

> and I don't see any evidence of non-randomness.

Again, just because you don't/can't see it isn't proof
that it doesn't exist.

Also, definition of randomness varies, especially if
coupled with the concept of fairness.

Another thing I often wonder is how the distribution
and much more importantly the dispersion of rolls
may be affected by the way numbers are generated
individually and then grouped by twos, threes, etc.
depending on how many dice need to be rolled, and
also dealt to each player in alternating order...? Can
a well dispersed series of single numbers become
badly clustered when paired alternatingly..?? (Many
times I suspected that dice rolls from random.org
may be suffering from this or something similar.)

> 3. The "never in real life" comment was sarcastic,
> as I read it.

Okay, sure but would it change what he said enough
for me to emend my comments? I admitted at times
that I have difficulty understanding Frank. What you
would say could help me with that. Exaggerating is a
common element of sarcasm but couldn't I talk about
it without worrying and/or saying something about if
he may have said it with sarcasm or not..? (Actually,
feel free to not elaborate on this if you don't want to.
Who gives a shit, really..?)

MK

On August 19, 2023 at 10:06:57 AM UTC-6, Tony The Welsh Twat wrote:

> I genuinely wonder what your view is of a developer
> of a backgammon app who is challenged (and refuses
> to acquiesce) to (a) display the RNG seed in use for
> any given game

This is a valid argument that has been made many
times over the years. Servers should use separate
instances of RNG's for users and disclose the seed
that was used for each game after it's completed.
The same applies to bots like Ex-Gee.

> and (b) give the user the option of playing a new game
> using that seed.

I don't see how would this help anything..? People
may be able to remember some recent sequences
of dice rolls and play differently the second time
around, which would amount to cheating...

MK

On August 19, 2023 at 1:51:48 PM UTC-6, Frank Berger wrote:

> Tony The Welsh Twat schrieb am 19. August 2023 um 18:06:57 UTC+2:

>> If you can prove definitively that your
>> app isn't cheating, why wouldn't you?

> Maybe .....

I think this is a good opportunity to give
Frank and his BG-Bzzt the due credit for
implementing the complete suite of all
possible dice rolling methods, (including
the desirable features for each of them),
that no other bot comes close to offering.

His bot includes:

1 - Several built-in RNG's which allow the
selecting of the initial seed (although I'm
not sure how the "counter" works).

2 - Getting dice from random.org

3 - Getting dice from an external DLL

4 - Reading dice from a file

5 - Manual dice input using the mouse
and/or the keyboard.

Manual dice is really the only way a bot
can't look at the upcoming dice rolls and
feeding a bot dice rolls from an external
process should be just as good, (unless a
bot can be so sophisticated to intercept
even those, which is virtually impossible).

With all this said and for all the hard time
I've been giving Frank, I wanted to make a
gesture to him by providing below, a very
simple sample code for an external utility
to feed manual dice to his bot. You can,
of course, improve it to use a better RNG
algorithm, to read dice from a file or even
fetch dice from random.org, which all will
look like manual dice to the bot. Enjoy... :)

MK

=================================#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

int seed, die1, die2;
byte keyp;
HWND xgdd;

int main() {

printf ("Enter seed: ");
scanf ("%d", &seed);
srand (seed);

while (seed > 0) {

while ((xgdd = FindWindow (NULL, "Get Dice")) == 0) {
sleep(1);
}

die1 = rand() % 6 + 1;
die2 = rand() % 6 + 1;

SetForegroundWindow (xgdd);

keyp = die1 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);

keyp = die2 + 48;
keybd_event (keyp, 0, 0, 0);
keybd_event (keyp, 0, KEYEVENTF_KEYUP, 0);

keybd_event (VK_RETURN, 0, 0, 0);
keybd_event (VK_RETURN, 0, KEYEVENTF_KEYUP, 0);

printf ("Rolled: %d %d \n", die1, die2);
sleep(1);
xgdd = 0;
}

exit(0);
} =================================
(The above code should compile okay using
even the most limited, portable C compilers.)

On 8/19/2023 8:43 PM, MK wrote:
> On August 19, 2023 at 10:06:57 AM UTC-6, Tony The Welsh Twat wrote:
>
>> I genuinely wonder what your view is of a developer
>> of a backgammon app who is challenged (and refuses
>> to acquiesce) to (a) display the RNG seed in use for
>> any given game
>
> This is a valid argument that has been made many
> times over the years. Servers should use separate
> instances of RNG's for users and disclose the seed
> that was used for each game after it's completed.
> The same applies to bots like Ex-Gee.

It's a valid argument, but it still wouldn't prevent someone from
claiming that the seed was calculated after the fact in order to
retrofit the dishonest sequence.

>> and (b) give the user the option of playing a new game
>> using that seed.
>
> I don't see how would this help anything..? People
> may be able to remember some recent sequences
> of dice rolls and play differently the second time
> around, which would amount to cheating...

If this is a concern, then many of the commonly used RNGs (e.g.,
Mersenne Twister) would no longer be suitable, because the seed
could be deduced after some number of rolls, especially if (as seems
to be commonly the case) people don't use the maximum possible seed
size.

---
Tim Chow

On Sunday, 20 August 2023 at 01:43:28 UTC+1, MK wrote:

> I don't see how would this help anything..? People
> may be able to remember some recent sequences
> of dice rolls and play differently the second time
> around, which would amount to cheating...
>
> MK

Well the app in question is almost certainly injecting iffy dice at various points (particularly during the end game).

By noting the dice generated by a given seed and then replaying the second game differently, those injections would occur at different times and therefore prove beyond all doubt that cheating was occurring.

Just to amuse you, the developer has responded to my latest request by calling it "dumb" :-)

Yeah, of course, proving beyond all doubt that your app isn't cheating sure is "dumb".

MK schrieb am Sonntag, 20. August 2023 um 04:15:44 UTC+2:

> 3 - Getting dice from an external DLL
just nitpicking: it's Groovy source code, no dll
>(although I'm not sure how the "counter" works).
I was bored by complains that "the bot is always getting more doubles" and the like. The counter simply skips the first N numbers, i.e. if the counter is 1 the first roll is skipped and you get the dice of the computer and vice verse. Not that have convinced anyone....

I further have implemented a live preview for the dice for the user recently ( http://bgblitz.com/images/HUD_t.png ) so *he* can see what dice will come and they not changed after a move. Naturally the user could cheat now, but the AI doesn't care ;) In fact complains have decreased since then, but I have no idea whether there is a correlation or it is only by accident.

On 8/18/2023 3:20 PM, glen moulder wrote:
> The only people who say that backgammon sites are not rigged are employees of 247, BG and VIP. It is soooo obvious. Can almost predict the next throw by the computer. I can be 25 pips ahead and almost ready to begin bearing off, and the opponent will suddenly roll a double 6 for "catch up". I can have my opponent on the bar with only one opening and way to hit me, and think, " the only way out is for the roll to be a 6 - 1" and that's what happens. Wish I could stop being seduced into playing. Wish, and would pay subscription money, to play in an "honest" game.

Yes, this is a problem that has been recognized for over 25 years.

Fortunately, we have a solution in the Official Complaint Form, which I
encourage you to download, fill out, and post the completed form here.

We have operators standing by to diagnose and address your problem.

See https://www.bkgm.com/rgb/rgb.cgi?view+546

HTH. HAND.

On August 20, 2023 at 6:58:30 AM UTC-6, Timothy Chow wrote:

> On 8/19/2023 8:43 PM, MK wrote:

>> On August 19, 2023 at 10:06:57 AM UTC-6, Tony The Welsh Twat wrote:

>>> display the RNG seed in use for any given game

>> This is a valid argument that has been made many
>> times over the years. Servers should use separate
>> instances of RNG's for users and disclose the seed
>> that was used for each game after it's completed.
>> The same applies to bots like Ex-Gee.

> it still wouldn't prevent someone from claiming
> that the seed was calculated after the fact in
> order to retrofit the dishonest sequence.

Yes and as I thought more about it, I realized that
actually it's much worse than that.

You were one of the people who have put a lot of
thought, if not any research, into this. I was going
to ask your opinion about emailing the encrypted
seed before the game and then emailing the key
after the game, similar to what you had proposed
in the past, like this about cryptographic protocols:

https://groups.google.com/g/rec.games.backgammon/c/u1npu-1FR9U/m/NphoLCBXj8AJ

But I quickly realized that if a server wants to make
a player win, it can pick one of thousands of seeds
that will give him a winning sequence of rolls, with
no need for retrofitting afterwards.

I wonder how many seed would start with a 52, 55,
dance, double, drop sequence? In fact, such similar
sequences may raise so much more suspicion that
I also wonder if servers may actually suppress them?

When we were talking about me playing online with
bets gainst bots, (or humans), I had said that being
disclosed the seed after each game would be good
enough for me to trust the server's dice. Thinking
back, I'm glad that no such bets took place because
I could have been made to loose bad... :(

>>> give the user the option of playing a new game
>>> using that seed.

>> I don't see how would this help anything..? People
>> may be able to remember some recent sequences
>> of dice rolls and play differently the second time
>> around, which would amount to cheating...

> If this is a concern, then many of the commonly
> used RNGs (e.g., Mersenne Twister) would no
> longer be suitable, because the seed could be
> deduced after some number of rolls,

Has this been ever tried to find out approximately
in how few rolls could it be done? If not, do you or
anyone here has an educated guess?

It was often said that the average number of rolls
in a game is about 54. If the seed can be deduced
in fewer than 54 rolls, it can give a huge anvantage
even if rarely and/or towards the end of the game.

If this is possible at all, some players can use it to
cheat their opponents even on most honest servers.

MK

On August 20, 2023 at 8:25:42 AM UTC-6, Tony The Welsh Twat wrote:

> On 20 August 2023 at 01:43:28 UTC+1, MK wrote:

>> I don't see how would this help anything..?

> By noting the dice generated by a given seed and
> then replaying the second game differently, those
> injections would occur at different times

If the app/server owner would already cooperate
to let players know the seed and replay using the
same seed, a less laborious solution would be:

1 - For the owners to provide a stand-alone utility
version of their RNG, so that users can enter the
same seed and see if it rolls the same sequences.

2 - For the owners to at least publish the algorithm
for their RNG, so that users can compile it to create
their own stand-alone utility that I mentioned above.

I had proposed this on many occasions, in the past,
regarding Ex-Gee for example, because even hough
"a source code" allegedly for its internal RNG, there
is no way to verify if it really is, (and thus, of course,
if the dice are random), because the seeds are not
shown nor allowed to be selected by the user. For
as long as owners refuse to offer such simple ways
to appease users, users will continue to justifiably
not trust them... :(

MK

On August 20, 2023 at 3:11:23 PM UTC-6, Frank Berger wrote:

> MK schrieb am 20. August 2023 um 04:15:44 UTC+2:

>> 3 - Getting dice from an external DLL

> just nitpicking: it's Groovy source code, no dll

Ah, okay. That must be Java equivalent of DLL?

>> (although I'm not sure how the "counter" works).

> The counter simply skips the first N numbers,

Jellyfish had this feature way back when. :) If you
chose a big number, you would sit there and wait
for it to internally go through all those rolls before
the game would start...

I wasn't sure if yours was the same because unlike
Jellyfish, BG-Bzzt doesn't increment and display it
if you look at it during the game.

> I further have implemented a live preview for the
> dice for the user recently

I saw that but didn't mention for not wanting to talk
about to many things at once. The semi-transparent
background was on both sides but for me numbers
appeared always on the right side (perhaps a bug?).

> In fact complains have decreased since then, but
> I have no idea whether there is a correlation

Maybe. Users can look for suspicious past moves
by scrolling the game record up and down, in other
bots. Volunteering it may have a preemptive effect.

MK

On August 20, 2023 at 4:21:04 PM UTC-6, ah...Clem wrote:

> On 8/18/2023 3:20 PM, glen moulder wrote:

>> The only people who say that backgammon
>> sites are not rigged are employees of 247...

> Fortunately, we have a solution in the Official
> Complaint Form, which I encourage you to
> download, fill out, and post the completed
> form here.

And I encourage you to go grab one of these

https://images.albertsons-media.com/is/image/ABS/184360005?$ng-ecom-pdp-desktop$

from you local market, go use it to satisfy your
spite somewhere else and then come back to
post here to tell us if it helped.

> We have operators standing by to diagnose
> and address your problem.

We are standing by to hear from you, hoping
that my presription cured your problem.

Next time, grab one for Wong also and tell him
to thank me :)

> HTH. HAND.

Looks like you forgot to sign your name, AH. Clem.

Get it..? A? H?

RSVP. ;)

MK

On 8/20/2023 10:14 PM, MK wrote:
> On August 20, 2023 at 6:58:30 AM UTC-6, Timothy Chow wrote:
>> If this is a concern, then many of the commonly
>> used RNGs (e.g., Mersenne Twister) would no
>> longer be suitable, because the seed could be
>> deduced after some number of rolls,
>
> Has this been ever tried to find out approximately
> in how few rolls could it be done? If not, do you or
> anyone here has an educated guess?

This is easy to estimate.

Let's say the seed is 32 bits. That means that there are 2^32
possible seeds.

There are 21 possible rolls. They're not all equally likely, but
we're just trying to estimate, so let's ignore that nuance. Now

21^7 < 2^32 < 21^8

So you should be able to infer a 32-bit seed after 8 rolls.

Now, if you were able to use the full 19937 bits available for the
Mersenne Twister, then this same calculation would say that you
would need over 4500 rolls to determine the seed. That sounds good,
until you realize that it also means that you could retrofit over
4500 rolls with such a large seed.

---
Tim Chow

On August 21, 2023 at 5:51:25 AM UTC-6, Timothy Chow wrote:

> On 8/20/2023 10:14 PM, MK wrote:

>> Has this been ever tried to find out approximately
>> in how few rolls could it be done? If not, do you or
>> anyone here has an educated guess?

> This is easy to estimate.
> Let's say the seed is 32 bits. That means that
> there are 2^32 possible seeds.

> There are 21 possible rolls. They're not all equally
> likely, but we're just trying to estimate, so let's
> ignore that nuance. Now

> 21^7 < 2^32 < 21^8
> So you should be able to infer a 32-bit seed after
> 8 rolls.

I don't believe you :) Can you demonstrate this
using Noo-BG, for example, which has a 32-bit
Mersenne Twister and allows setting the seed?

You may want to read what you had said on this
in a thread titled "Re: How fast can you cheat??"
that I had started in 2009, which included some
long discussions about Noo-BG and Mersenne
Twister:

https://groups.google.com/g/rec.games.backgammon/c/-Y9AWXOFwrc/m/3OUC6_UoWyUJ

In one post, when I had asked you:

>> What do you say to that, "Moses"...??? :)))

You had answered:

> ..... The Mersenne Twister algorithm becomes
> predictable after a while, but this loophole can
> again be plugged if we simply agree to refresh
> the seed after a certain period of time. We'd
> have to check the details of the generator to be
> certain, but the number of dice rolls in a 31-point
> match is probably small enough that refreshing
> the seed after each match is good enough.

> Wikipedia says that 624 observations of MY19937
> is enough to recover the seed, but I think this
> assumes that you see the full 32-bit word each
> time, so it probably translates into more than 624
> dice rolls.

This was so easy to find by just searching for 624
in the RGB... :)

About your last sentence above, I think Ex-Gee and
Noo-BGt derive dice numbers simply from modulo
6 of those 624 numbers in the array. So, one would
need to know all 624, (i.e. at least 312 dice pairs),
in order to know the following roll in line.

We were also talking about long 31-point matches
which would have fewer than 53*31=1,674 rolls on
the average, since we now know that the effective
match lengths decrease increasingly. But even so,
surely they wouldn't be shorter than 312 rolls. See
this recent post about average rolls in matches of
13 and 19 points in gamblegammon:

https://groups.google.com/g/rec.games.backgammon/c/fpTQofI7-Hk/m/ZYV5kPt3BwAJ

Yet, you had said "number of dice rolls in a 31-point
match is probably small enough that refreshing the
seed after each match is good enough".

And now you are saying "you should be able to infer
a 32-bit seed after 8 rolls".

Can you stand behind either of these contradicting
statements..?

MK

On 8/23/2023 6:08 PM, MK wrote:
> I don't believe you :) Can you demonstrate this
> using Noo-BG, for example, which has a 32-bit
> Mersenne Twister and allows setting the seed?

I doubt that you'd be convinced by anything short of working code,
and I'm not going to produce working code, because someone might
actually use it to cheat.

In any case, while I'm happy to point you in the right direction,
I'm not going to try to overcome your skepticism. If you're too
lazy to learn the math, or prefer to sting like a scorpion because
that's your nature, then that's your problem.

>> ..... The Mersenne Twister algorithm becomes
>> predictable after a while, but this loophole can
>> again be plugged if we simply agree to refresh
>> the seed after a certain period of time. We'd
>> have to check the details of the generator to be
>> certain, but the number of dice rolls in a 31-point
>> match is probably small enough that refreshing
>> the seed after each match is good enough.
>
>> Wikipedia says that 624 observations of MY19937
>> is enough to recover the seed, but I think this
>> assumes that you see the full 32-bit word each
>> time, so it probably translates into more than 624
>> dice rolls.

Here I was assuming that the full 19937 bits of the seed were being
used, not just 32 bits of it.

> About your last sentence above, I think Ex-Gee and
> Noo-BGt derive dice numbers simply from modulo
> 6 of those 624 numbers in the array. So, one would
> need to know all 624, (i.e. at least 312 dice pairs),
> in order to know the following roll in line.

Again, this would only be if the full seed were being used.

> Can you stand behind either of these contradicting
> statements..?

There is no contradiction.

---
Tim Chow

On 8/24/2023 8:18 AM, I wrote:
> On 8/23/2023 6:08 PM, MK wrote:
>> I don't believe you :) Can you demonstrate this
>> using Noo-BG, for example, which has a 32-bit
>> Mersenne Twister and allows setting the seed?
>
> I doubt that you'd be convinced by anything short of working code,
> and I'm not going to produce working code, because someone might
> actually use it to cheat.

If you want to try it yourself, here's a sketch of how to write some
code. It's not the most efficient algorithm (it would be more efficient
to solve a system of linear equations over a finite field), but it
should work.

Obtain 8 rolls. Then try all 2^32 possible 32-bit seeds to see if you
can match the given rolls. Unless you're very unlucky, only one of the
32-bit seeds will give you a match. You can then confirm that it gives
the same remaining dice rolls.

---
Tim Chow

On 2023-08-23, MK <murat@compuplus.net> wrote:

> I don't believe you :) Can you demonstrate this
> using Noo-BG, for example, which has a 32-bit
> Mersenne Twister and allows setting the seed?

In GNUbg the seed for Mersenne twister is not limited to 32 bits. The
way to set it from the GUI had a bug but this was fixed in 2019 after a
vigilant user reported the problem:

"Allow RNG seeds up to 2^53 in the GUI (when built with libgmp) instead
of truncating them at 2^32. This prevents an issue reported by Murat in
rec.games.backgammon when using a timestamp in yyyymmddHHMM format as
seed."

2^53 shoud be more than enough to make the brute-force sifting described
by Tim in another post impossible *if* the seed is really not guessable.

On August 24, 2023 at 6:18:41 AM UTC-6, Timothy Chow wrote:

> On 8/23/2023 6:08 PM, MK wrote:

> > I don't believe you :) Can you demonstrate this
> > using Noo-BG, for example, which has a 32-bit
> > Mersenne Twister and allows setting the seed?

> I doubt that you'd be convinced by anything
> short of working code,

I wasn't thinking anything of no such things
at all. I'll be satisfied if I give you 8 rolls and
you tell me what was the seed I used.

> I'm not going to produce working code, because
> someone might actually use it to cheat.

This sounds eerily deja vu. I can't be sure who
had said it but his reason for refusing a similar
request was exactly the same. In this case, I'm
not even asking for it.

> If you're too lazy to learn the math,

To the contrary, I'm asking you because I want
to learn the maths but I wouldn't want to learn
the wrong math/s.

> or prefer to sting like a scorpion because
> that's your nature, then that's your problem.

Whoa! Slow down, turtle! No need to call out to
scorpions (not yet anyway ;)

>>> The Mersenne Twister algorithm becomes
>>> predictable after a while, but this loophole
>>> can again be plugged if we simply agree to
>>> refresh the seed after a certain period of time.
>>> We'd have to check the details of the generator
>>> to be certain, but the number of dice rolls in a
>>> 31-point match is probably small enough that
>>> refreshing the seed after each match is good
>>> enough.

>>> Wikipedia says that 624 observations of
>>> MY19937 is enough to recover the seed, but I
>>> think this assumes that you see the full 32-bit
>>> word each time, so it probably translates into
>>> more than 624 dice rolls.

> Here I was assuming that the full 19937 bits of
> the seed were being used, not just 32 bits of it.

I wasn't making an issue out of 19937 vs 32 bits.

>> About your last sentence above, I think Ex-Gee
>> and Noo-BGt derive dice numbers simply from
>> modulo 6 of those 624 numbers in the array.
>> So, one would need to know all 624, (i.e. at least
>> 312 dice pairs), in order to know the following
>> roll in line.

> Again, this would only be if the full seed were
> being used.

If you are going to respond to me without reading
what I write, what's the point of discussing..? I'm
not going to repead what I had written after what
you quoted from my post. You can go back and
read it again. But I'll add a few lines quoting from
myself in the link I had given, (which apparently
you didn't bother to read either):

"Lo and behold! Your total moves for a 5-point
"cubeless gamblegammon match is 324, for a
"13-point cubeful gamblegammon match is 351.
"Similarly, for a 7-point cubeless gamblegammon
"match is 465, for a 19-point gamblegammon
"match is 530.

Thus, a 31-point gamblegammon match is likely to
last about 700 some moves/rolls. And even using
the full 19937 bits of the seed, if you can deduce it
only after 624 numbers, i.e. 312 dice rolls, then you
you will start knowing the upcoming numbers only
halfway through a 31-point gamblegammon match.

When I asked: "Can you stand behind either of these
contradicting statements..?", I was asking if you can
stand behind your statement that "refreshing the seed
after each match is good enough in 31-point matches".

If I have to explain what I write like to a 5-year-old kid
too often, I may grow tired of it... :(

> There is no contradiction.

Well, maybe not literally but I was trying to contrast
your claim to deduce a 32-bit seed after only 8 rolls,
(which I believe are too few), against to not deduce a
19937 bit seed even after 312 rolls, (which I believe
are too many).

So, let me ask again trying to be clearer this time:

1- Do you accept that you were overestimating the
dice rolls needed to deduce a 19937 bit seed? (No
additional arguments needed).

2- Do you accept that you were underestimating the
dice rolls needed to deduce a 32 bit seed? (If not, I'd
like you to demonstrate that your math is correct for
me to learn the math correctly).

MK

On August 24, 2023 at 6:24:04 AM UTC-6, Timothy Chow wrote:

> Obtain 8 rolls. Then try all 2^32 possible
> 32-bit seeds to see if you can match the
> given rolls. Unless you're very unlucky,
> only one of the 32-bit seeds will give you
> a match.

And how many 32-bit seeds will give me
a match, if I'm indeed very unlucky..." :)

MK

On August 24, 2023 at 7:14:51 AM UTC-6, Philippe Michel wrote:

> On 2023-08-23, MK <mu...@compuplus.net> wrote:
>> I don't believe you :) Can you demonstrate this
>> using Noo-BG, for example, which has a 32-bit
>> Mersenne Twister and allows setting the seed?

> In GNUbg the seed for Mersenne twister is
> not limited to 32 bits. The way to set it from
> the GUI had a bug but this was fixed in 2019
> after a vigilant user reported the problem:

> "Allow RNG seeds up to 2^53 in the GUI (when
> built with libgmp) instead of truncating them
> at 2^32. This prevents an issue reported by
> Murat in rec.games.backgammon when using a
> timestamp in yyyymmddHHMM format as seed."

Thanks for reminding. :) I couldn't remember
which was which and how they were fixed. :(

Jellyfish and Snowie had the same problem.
Talk about "bott fucking"... ;) In fact, Snowie's
was signed 32-bit, so you really had 16-bits,
even though in all three bots you cound enter
numbers larger than 32-bits. I think it was a
problem with Jellyfish itself going from 16 to
32 bits. I think in one or two bots it was fixed
by simple range check during input but I wasn't
sure if/how it was fixed in all bots.

Can you folks imagine all those extraterrestrial
bots not being able to get something so fucking
simple as seeding their RNG's right... And then
they feel offended when we piss on then and ask
what else more important things may be wrong
with their pieces of shit so-called AI bots... :(

> 2^53 shoud be more than enough to make the
> brute-force sifting described by Tim in another
> post impossible *if* the seed is really not
> guessable.

No need. I have the pre-2019 Noo-BG EXE's. If
Tim is up to demonstrating his math, we can
just use one of those...

MK