• (disco)

    Wait, is there supposed to be some kind of input to this? It sounds like we're just supposed to implement yet-another-prng....

  • (disco) in reply to Tsaukpaetra

    I just presumed (at a minimum) a count of numbers to produce. And somehow produce some semi-predictable output.

  • (disco) in reply to PJH

    Oh OK. I was thinking maybe to spy on some specific memory address or trigger file.

  • (disco) in reply to Tsaukpaetra

    Could do it that way if you want to switch on/off the predictable behaviour.

  • (disco) in reply to Tsaukpaetra

    I don't think implementing your own RNG will get you far. After all, some clever intern can just replace it with a call to rand() and you lose a million dollars betting on the wrong number.

    The point is to handle the requirements in a way that appears to make sense, but is just slightly off-beat. As for input - since it's a roulette, you may have the number of rolls, or intervals between requests, or some other side-channels...

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    Oh OK. I was thinking maybe to spy on some specific memory address or trigger file.

    But how would the end user write to that specific address? This is a module for an online casino. In fact, that one point makes one of the proposed avenues for this problem improbable: you are only writing the number "selection" module in such a way that it knows (and relies on) the historical output it produced. The ability to enter a cheat code that can be turned on or off requires access to the UI. In order to really stick to the backstory, you pretty much have to go with the predictable route.

  • (disco) in reply to abarker

    Indeed. So it's basically, "write a number generator that seems to make random numbers but is actually very bad at it."

  • (disco)

    Hold on a second... let me find [redacted]'s old code for [redacted] Casino written [redacted] years ago...

  • (disco)

    just do to random chance

    text review, just do it.

    before 11:59PM Eastern Time, Sunday the 10th of August

    Wow, timezones are even more screwed up than I thought. Over here 10th is Monday.

  • (disco) in reply to obeselymorbid
    obeselymorbid:
    Wow, timezones are even more screwed up than I thought. Over here 10th is Monday.

    nah. it's a year issue. @Remy left out the year of the due date is all.

    /me looks at the calendar....

    looks like the entries are due either august 10 2014 or august 10 2025

  • (disco) in reply to abarker

    Well it is supposed to be a online system (that is a web-accessible thing).

    Assuming it will be written in PHP or Perl, you could 'switch on' the bug by querying for a specific HTTP_USER_AGENT which you could then craft with the proper browser add-on.

    The trick would be to hide the code for the user agent sniffing enough, but at least in Perl it would be possible to bury it in a completely incomprehensible regexp (then you only need to figure out a somewhat plausible reason for using a regexp in a prng in the first place, but it could conceivable be to comply with the requirement about not too random.)

    If in doubt about the regexp, then just check the perl version of 99 bottles of beer...... :smile:

    Almost tempted to try it out.... :smile:

  • (disco) in reply to Yazeran
    Yazeran:
    The trick would be to hide the code for the user agent sniffing enough

    hex2dec(left(md5(HTTP_USER_AGENT), 8)) == 42

    now you just have to find a reasonable looking user agent that produces an MD5 sum where the first 8 digits = 42 (you may wish to add more maths to that to further obfuscate that. also it's probably not going to be a good idea to do that all on one line.)

  • (disco) in reply to accalia

    Yep. That might work :smile:

    An other approach to actually control the numbers would be for the last character of the user agent string to be used as a basis for the next 'random number' to be generated (when 'cheat mode' is switched on), so that you could accurately control the number you get (and potentially switch during your cheating session to avoid drawing suspicion that '42' continues to show up.... :smile: )

  • (disco) in reply to Yazeran

    oh. now that i like....

    hmm.......

    /me plots

  • (disco)

    Roulette's house advantage is already fairly slim - between 2.7 and 5.6%. A PRNG that meets the requirements provided is already going to be nonrandom enough that if you know its constraints you can beat the house, no exploits required.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    "write a number generator that seems to make random numbers but is actually very badclever at it."

    FTFY

  • (disco) in reply to Nick_Johnson
    Nick_Johnson:
    A PRNG that meets the requirements provided is already going to be nonrandom enough that if you know its constraints you can beat the house

    Not quite. Even if we take a French board (single 0). I assume that the average advantage of the cheater (aka programmer) is the same as if no runs were allowed without any other restriction.That would make the game just fair for anyone knowing this constraint.

    If we'd rule out sequences like 23, 24, 25, 26 or 19, 18, 17, 16 otoh ...

    (Which I'd prepare to implement for this is one of the requirements you can be sure to come up short- or medium-term.)

  • (disco) in reply to Yazeran

    It can be web based, console based, client gui- whatever. Solve the problem however you want, and don't get hung up on the idea that it's supposed to be a module that's part of a larger application. That's just the "fluff".

  • (disco) in reply to Nick_Johnson
    Nick_Johnson:
    Roulette's house advantage is already fairly slim - between 2.7 and 5.6%. A PRNG that meets the requirements provided is already going to be nonrandom enough that if you know its constraints you can beat the house, no exploits required.

    It's a double-zero, so 5,6% for pretty much any bet save for the five-number one. And even with the streak rule it doesn't help you much - even if you bet only after a three number streak (and that would probably get you kicked out of the casino together with that card counter at the blackjack table), you've only eliminated a single number from the pool - basically temporarily making it a single-zero roulette at best, depending on the bet.

  • (disco)

    <buzzkill>So, does this mean we don't get a WTF today?</buzzkill>

  • (disco) in reply to bogolese
    bogolese:
    <buzzkill>So, does this mean we don't get a WTF today?</buzzkill>

    At the risk of seeming a bit negative and all, I'd say that so far, the comments are TRWTF for today.

  • (disco) in reply to PWolff
    PWolff:
    (Which I'd prepare to implement for this is one of the requirements you can be sure to come up short- or medium-term.)

    Sounds to me like this code needs some serious future-proofing. <evil idea>

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    At the risk of seeming a bit negative and all, I'd say that so far, the comments are TRWTF
    QFT
  • (disco) in reply to Tsaukpaetra

    The article says the RNG isn't important - it's the massgaing out the output from the RNG that counts.

  • (disco) in reply to Remy
    Remy:
    It can be web based, console based, client gui- whatever.

    How about FORTRAN punch-cards? :laughing: You don't actually need a punch-card system, you can have your authors act as interpreters.

    Or...erm...hire interns and leave the authors out of it actaully? :facepalm:

  • (disco) in reply to mott555
    mott555:
    Or...erm...hire interns and leave the authors out of it actaully?

    Yeah, you might want to bite your tongue once in a while, don't you.

  • (disco) in reply to PWolff

    True. A simple solution that would meet all the requirements and still be trivial to game if you know what's going on, though, would be to exclude the 3 most recent draws from consideration. My basic point being that most solutions to the actual problem are likely to eliminate the casino's edge if exploited, so no actual exploit/hack is required.

  • (disco)

    If I wanted to write intentionally bad code, I'd just start blindly doing whatever requests management wants at work instead of telling them why X is a bad idea.

  • (disco) in reply to Nick_Johnson
    Nick_Johnson:
    My basic point being that most solutions to the actual problem are likely to eliminate the casino's edge if exploited, so no actual exploit/hack is required.

    I don't think that'd be a good solution either. After a week, tops, they'd find out that in the long run they're not getting any money.

    The point is so that you can profit on that (the actual requirement is "to make the roulette output predictable", but lowering the house's edge so that you can turn a profit in the long run probably would work too), but not anybody else. I suppose a good solution would have something like a secret sequence of bets which then makes the output generate a predictable sequence, and not have the roulette generate a non-random sequence for anybody, too.

    Besides, as @Remy said, and as far as I remember OMGWTF contests, those aren't hard rules.

  • (disco) in reply to Steve_The_Cynic
    Steve_The_Cynic:
    At the risk of seeming a bit negative and all, I'd say that so far, the comments are TRWTF for today every day.

    FTFY

  • (disco)

    Just rig it to skip over MD_Update(&m,buf,j); when you type in "purify".

  • (disco)

    Strategy:

    1. Use WPF.
    2. Use Infragistics' XamDataGrid.
    3. Somehow incorporate shift-click-dragging upwards.
    4. Watch the app crash, or praise them for fixing a bug.

    Seriously, when you give out samples of how great your controls are and that happens? You need to actually hire QA.

  • (disco) in reply to bogolese
    bogolese:
    <buzzkill>So, does this mean we don't get a WTF today?</buzzkill>
    No, you're supposed to write one for the dishonest bastard casino programmer that submitted this and is partying in his motel room until the 10th.
  • (disco) in reply to PWolff

    Assuming a single 0 board all you need to do to win is figure out how long it's history is, keep track of those rolls and never bet on anything in the history.

    I have a big problem with this challenge as any reasonable generator will not have access to any input source to be used to provide the side-channel communications needed. The only input data there is is the system clock and given the delays of the internet that's a pretty darn low bit width channel.

  • (disco)

    Mkay, here's one, it linearly lowers the probability that a number will be repeated, the closer it is to being a recent number:

    And you don't need a trigger for the cheating part, it repeats every 2^31 rolls, so you just keep a rainbow file of all the rolls and search for the recent rolls....

    1

    Javascript example no.2

    2 <input type="text" id="myTextField"/> 3 <input type="submit" id="byBtn" value="Change" onclick="change()"/>

    JavaScript

    1 // generate "more random" roulette wheel spins 2

    3 // [email protected] 4

    5 var Out = ''; 6 log = "|"; 7 seed = 123456789; 8 maxsave = 20; 9 recur = 0; 10

    11 function Print(Msg) { 12 Out = Out + Msg + ","; 13 } 14

    15 function WheelNum(x) { 16 if (x < 0) { 17 x = "00"; 18 } else { 19 if (x > 0 && x < 10) { 20 x = "0" + x; 21 } else x = x + ""; 22 } 23 return x; 24 } 25

    26

    27

    28 function rand() { 29 seed = (1103515245 * seed + 1234567) % (1 << 31); 30 return seed; 31 } 32

    33 function Ran() { 34 recur += 1; 35 hash = Math.floor(rand() / 12); 36 ret = hash % 36; 37 ret = ret - 1; 38 txt = WheelNum(ret); 39 if ( ( Math.random() * maxsave ) > ( log.indexOf("|" + txt) / 3 ) && recur < maxsave ) { 40 ret = Ran(); 41 } 42 txt = WheelNum(ret); 43 log = txt + "|" + log; 44 log = log.substr(0, 20 * 3); 45 recur -= 1; 46 return ret; 47 } 48

    49

    50 function Spin() { 51

    52 for (i = 0; i < maxsave * 30; i++) { 53 Print(WheelNum(Ran())); 54 } 55

    56 document.getElementById('output').innerHTML = Out; 57 }

  • (disco) in reply to Nick_Johnson
    Nick_Johnson:
    Roulette's house advantage is already fairly slim - between 2.7 and 5.6%

    Extremely fat, actually. If in a real casino with a full table there are 7 rolls per hour, that's an interest rate to the casino of from 19 and 39%. With online gambling it is much higher. That's hugely profitable. Compare it to a weekly lottery where the advantage to the house is around 67% (not unusual) and you will see that the rate at which money is removed from suckers is many, many times higher for roulette, even though the apparent house advantage is small.

    People who can control their gambling and visit real casinos argue that it is actually cheaper than watching pro football or grand opera, and this is true. But a lot of the people who play online roulette are problem gamblers.

  • (disco) in reply to LorenPechtel
    LorenPechtel:
    never bet on anything in the history
    Moot after 37 (resp. 38) rolls.
    LorenPechtel:
    any **reasonable** generator
    (Emphasis by me)

    Want a badge?

  • (disco)

    So they want a version of Appl'e iTune Shuffle?

  • (disco)

    This "streak" requirement is kinda like making a wager on red if black turns up 4 times in a row. Wasn't that the subject of a programming challenge a while ago?

    History repeats.

  • (disco)
    ...the same number may appear many times in a row, just do[sic] to random chance.
    Why in the hell would Remy write (and then call out) a fake typo in the fake quote that he himself wrote?
  • (disco) in reply to Zylon

    presumably it's supposed to come uncorrected from the figurative client from hell the narrator works for.

  • (disco)

    The simplest Perl 6 code that satisfies the requirements of the Casino is the following which produces an infinite list of numbers. It will of course never even produce two of the same number in a row. It also doesn't qualify for submission. It does have the nice property that it would obviously work for what the Casino wants.

    (0,0..36).roll(*).squish
    

    If you wanted it to be able to produce two in a row, also as an infinite list.

    my constant $double-zero = ( 0, 0..36 );
    
    multi sub generate () {
      my @last = $double-zero.roll(2);
    
      gather loop {
        my $next = $double-zero.roll;
    
        # pick a new value if both of the previous two match it
        redo if $next == all @last;
    
        @last = @last[1], $next;
    
        take $next;
      }
    }
    
    multi sub generate ( :$hijacked! ){
      flat (0,0..36) xx *
    }
    

    Oh look I can highjack it, if I give it a named argument of highjacked.

    say generate :highjacked
    

    ( I know this isn't how to submit an entry )

  • (disco) in reply to PWolff

    The instructions were to avoid recent rolls--the history is going to be a lot shorter than 38 items.

    And my comment about a reasonable generator is that any generator looking at resources it has no business looking at should stand out like a sore thumb and thus not meet the subtle requirement.

  • (disco) in reply to LorenPechtel
    LorenPechtel:
    any generator looking at resources it has no business looking at

    All it needs is its own history (I assume it is the only prng the casino would use, otherwise it couldn't be guaranteed that no number comes up three times in a row).

    Besides that, a cheat code to be entered is well within scope of the spec (not of the fictional casino, of course, but of the challenge).

  • (disco)

    I'm not entering this because I just don't write code nowadays through age and incompetence, but some time ago I put a resource on the web showing an approach to designing a program that would over a period have a slight advantage over a human player at rock,paper,scissors. Nobody was interested (see first line) but it's probably still out there and discusses a Python implementation with data stored in JSON.

    The idea of using specially crafted headers to turn cheat mode on and off assumes that the system architect isn't doing what I would do in J2EE - that is to say capturing all responses in a top level servlet which hands off only the essential data to the various workers. If all you are doing is providing me with a pseudorandom number to my spec, I'm certainly not about to let you read headers. In fact, in a properly designed program I can't see how you would do it unless you were the system architect or the lead for the top level response handler.

    If I had total control of the design of the program I would make use of a key. In real roulette one player can make multiple bets on the same turn, so I would code a pattern like $5 on 9, $25 on 17, $10 on impair, $25 on rouge... with a corresponding bet pattern to turn off. Given I know what will happen, I will soon recoup the losing bets to start the cheat. But given the sort of guys who run these things it would be far, far more sensible to spend the time and the money, say, investing in one of Mr. Adelson's enterprises. You might still lose money but you will be able to walk away.

  • (disco)

    Couple of questions:

    1. Can the Cheat Bet be for any legitimate roulette bet i.e. Black / Red; Street / Corner etc. Or does it have to be a Straight?
    2. Does the Cheat Bet have to win every time?

    Remember: The cheat has to go undetected and it has to be predictable. Which is something of a contradiction.

    Also, some clarification on the requirements:

    1. My interpretation is that only a random number generator only is required. I.e. something that outputs a single number, either automatically of as a result of some "trigger". TBH That is what the competition is about, and you have already stated that a UI is not required.
    2. Does it need (for the purposes of the competition) to be an exact simulation?
    3. In theory, over time, random numbers will have an even distribution (if that is the correct term) i.e. each number will appear the same number of times. Again, for the purposes of the competition, can this "time" be reduced to say after 3600 generated numbers, the distribution would be even - I don't want you spending the rest of your life testing my submission.
    4. How can we prove the "cheat", if we tell what it is then how can you claim that it is insufficiently disguised?

    Also, in relation the last point: The code to perform the actual requirements is incredibly simple. Therefore any "cheat" code will stick out like a monk in a nunnery. If is doesn't, then "you will know where to look for it".

    Thank you.

    :hanzo: Edit: Oh yeah, should I submit, and should I win: I want a cut of the profits when the code goes into production.

  • (disco) in reply to loose
    loose:
    Remember: The cheat has to go undetected and it has to be predictable. Which is something of a contradiction.

    Yeah, this to me is the most significant point. If a million people are going to be using this code and trying to find patterns in the output in order to win... how can you make the output predictable yet at the same time make sure they won't figure out how to predict it?

    You almost have to go with the other option, which is embed a cheat somehow to turn on/off the predictable nature. However, this is going to depend heavily upon the GUI and the system upon which it runs. The user-agent string is a decent idea, although repeatedly changing your UA isn't a typical user behaviour and who knows if it might trip some red flags.

  • (disco) in reply to loose
    loose:
    In theory, over time, random numbers will have an even distribution (if that is the correct term) i.e. each number will appear the same number of times. Again, for the purposes of the competition, can this "time" be reduced to say after 3600 generated numbers, the distribution would be even - I don't want you spending the rest of your life testing my submission.

    To nitpick, the number of turns would need to be 3700 or 3800 depending on whether it's a European or a US wheel. However, if every number occurred 100 times in each cycle, the distribution would not be random, it would be pseudorandom.

    anotherusername:
    how can you make the output predictable yet at the same time make sure they won't figure out how to predict it?

    Any interference with randomness produces a vulnerability that an attacker can exploit, but in roulette the house advantage means that the attacker may still lose. For instance, suppose by long observation the attacker notices that the same number never occurs 4 times in a row. Let's assume that 3 comes up three times in a row. You know the next number will not be 3. However, you can only bet against 3 by choosing some other number; the odds are then 36:1 (EU) or 37:1 (US) that you are right, but the payout is 36:1, so in Europe you can only break even and in the US the advantage is with the house. (Now you know why Mr. Adelson is so rich.) This leads to the remarkable observation that the house might, in roulette, actually create a non-randomness for an attacker to detect, because thinking they have beaten the system may keep them playing when in fact they will continue to lose over time.

    Roulette is a wonderful way of teaching statistics - and also psychology.

  • (disco) in reply to kupfernigk
    kupfernigk:
    To nitpick, the number of turns would need to be 3700 or 3800 depending on whether it's a European or a US wheel.

    Gotcha! :)

    The requirement is to "make" it feel random - to human perception, not to make it truly random.

    The (a) best random number generator (because it is purely mechanical) is the UK lottery, and I can assure you there is an even distribution. So much so that if you bet on the "less" frequent numbers they will come up quite quickly. Unfortunately, not in the same draw.

    Note: There is an argument that the only truly random numbers are those that are computer generated - because they are "forced" to be random. In reality, the same numbers come up surprisingly frequently.

  • (disco) in reply to loose
    loose:
    Couple of questions:

    Can the Cheat Bet be for any legitimate roulette bet i.e. Black / Red; Street / Corner etc. Or does it have to be a Straight? Does the Cheat Bet have to win every time?

    As far as I understand it, what you bet on doesn't matter, and wheter you win or not is determined by what you bet on, it is only required that you know what number will follow.


    @Remy

    Is it necessary to be able to predict the accurate outcome of the next roll, or is it sufficient if the distribution is skewed enough to have a positive expectancy value of net win?

Leave a comment on “Introducing the Lucky Deuce”

Log In or post as a guest

Replying to comment #454729:

« Return to Article