# A proof-of-work random number generation system for Pokémon [closed]

(The original question that was here was considered too confusing, unclear, and rambling. You can still view it in the edit history, but the content is no longer useful by itself, and cannot be reasonably reconstructed into a question suitable for this site. The question object is still here by decision of a moderator, as a placeholder to preserve any reputation gained by the answerers of this question while it was still active, as well as to preserve the original question content in case any new questions are built upon this one.)

-

## closed as not a real question by Thomas, Paŭlo EbermannJan 20 '13 at 0:51

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.

I've realized that in its current form, this question is very confusing, unclear, and unsuitable for this website. I'm currently writing a paper to formalize the system, which I will submit in a new question. –  Joe Z. Jan 19 '13 at 4:44
The paper is here, by the way: joezeng.com/papers/pokegen.pdf –  Joe Z. Dec 6 '13 at 21:09

It is hard to tell from this question, but I suspect that you may have managed to confuse yourself about what problem you have: i.e., that you've gotten caught up in a particular mechanism, and would benefit from taking a moment to step back and look at the actual requirements. I found it hard to extract the actual requirements from your question.

In these situations, it's always a good idea to ask yourself the question: What is my threat model? What kinds of threats do you need to defend against? What kinds of attack vectors are possible for an attacker?

For instance, a crucial question is: do you trust the game software that is running the game? It sounds like you want to say that you don't trust the software, but that leads you to an unsolvable problem.

Or, to put it another way, it seems like there's a simple solution to your problem. Your game software can generate truly random numbers using a suitable random number source (e.g., /dev/urandom or CryptGenRandom). There doesn't seem to be any reason to use a deterministic PRNG, and no reason for the random numbers to be derived from untrusted user inputs. Doesn't this solve all your problems? Why are you going into such complicated stuff, when there's a much simpler way to generate random numbers that also happens to eliminate the issues you're worried about? Is there some requirement that I'm missing?

If you're about to say "but the user could modify the game software's RNG to bias its output", my response will be "yes, that's always possible, and nothing you will ever do will ever be able to stop that". Realistically, you can't prevent reverse-engineering of your software. The user who is running your software could always run a modified version of your software that gives them better stats, and no amount of cryptography is ever to make that impossible. But in any case, these are the kinds of questions you should be working out when you think through your threat model.

I confess I had a hard time understanding what proof-of-work has to do with trusting that the random numbers you generate are trustworthy.

-
I realized a long time ago that the user could modify the software's RNG to bias its output. Basically, what I want to do is to use some sort of predetermined algorithm that generates "random" numbers, and have people mine for pre-images if they want favourable results. –  Joe Z. Jan 3 '13 at 15:30
Basically, I don't actually care that the random numbers generated are trustworthy. All I want to do is to make people who want favourable results have to mine for them in a random, Bitcoin-like process. –  Joe Z. Jan 3 '13 at 15:43
@JoeZeng You require a trusted server to accomplish this, which'll check the result and broadcast to other players (or certify on request) that such and such user did successfully complete the work. Or you could use a p2p network, Bitcoin style, but this gets rather unreasonable for a Pokemon game at this point, no? –  Thomas Jan 3 '13 at 16:35
The trusted server would be, for example, a tournament server. The trusted server being involved in verification is okay; only it shouldn't be involved in generation. –  Joe Z. Jan 3 '13 at 16:47
You're right, I do need to clarify my threat model. I'll do that as soon as I figure exactly what it is myself (I only have a vague idea for now, as this was an idea that was casually thrown around from time to time). –  Joe Z. Jan 3 '13 at 19:03

Here is one simple solution.

After a new user installs the Pokemon software, before the new user can use that software (for tournament-eligible activities), they must register it with a central tournament server. The tournament server gives the user's software a random 128-bit seed $S$, and remembers this seed. The Pokemon software now creates a cryptographic-strength PRNG, seeded by $S$. At any point during game play that requires a new random number, the random number is obtained by pulling another output from the PRNG.

This allows off-line gameplay. If the user then wants to participate in a tournament server, they can later re-connect to the tournament server and prove that the Pokemon characters they generated have suitable stats by demonstrating that they were generated from the PRNG, using the seed $S$ that was assigned to them. Since the cryptographic PRNG is a deterministic function, this provides limited leeway for the sort of attacks you are talking about.

I can't tell if breeding really requires any special handling. If it does, here's one way to handle it: when you breed a new child, generate a 128-bit value $S'$ from the parent's PRNG. Then, use $S'$ as the seed for a PRNG associated with the child. This way, each Pokemon character has its own PRNG associated with it, seeded using a value that was in turn generated from some other PRNG (namely, it's parent's PRNG -- except in the case of parentless characters, which have their seed generated by the global PRNG, which in turn was seeded using the value $S$ obtained at registration time from the central server).

Does this do the trick?

-
I want to say yes, but I'll have to think it through for a while. If it does go through, this answer will probably be accepted. I'll keep you posted with any things I've thought up with comments to this answer. –  Joe Z. Jan 6 '13 at 3:54
The reason breeding needs special handling is because some of the generated values must match the parents' generated values - it can't be just the pre-images that match, which means that there needs to be some extra proof-of-work on the offspring. –  Joe Z. Jan 6 '13 at 4:30
Okay, so, I'm not sure quite what you mean by using $S$ as the "seed" of the PRNG. Do you mean that it's sort of a global prefix to any pre-image for a CPRNG in counter mode? If so, yes, that would work, and it also has the added benefit of allowing timestamps to further reduce the attack space. If not, I'd need clarification on what sort of PRNG you're talking about, and how you'd be able to prove that they were generated from the PRNG in the first place. –  Joe Z. Jan 6 '13 at 4:33
No, he means that it's the initial state for an algorithm that outputs a stream of bits. $\hspace{1 in}$ –  Ricky Demer Jan 6 '13 at 5:59
@JoeZeng, my apologies for being dense, but I did not understand any of your explanation why breeding needs special handling. As far as what is meant by a "seed", you might want to read about cryptographic PRNGs and how they work. The short version is that they generate an infinite stream of outputs $(y_1,y_2,y_3,\dots)=G(S)$ as a deterministic function of a seed $S$. Given any subset of the $y_i$'s, you cannot predict any of the other $y_j$'s or the seed $S$ better than blind guessing. –  D.W. Jan 6 '13 at 7:57

Fundamentally, all you can do is make it "hard" to roll a character. For example, if it takes about five seconds of computation to roll a character, that will annoy ordinary users as they wait 5 seconds, but it will limit cheaters to 12 rolls per minute. Of course, cheaters can always get their hands on more computing power, and the delays will annoy non-cheaters.

You can always limit users to a fixed number of rolls, say 5,000. At least that will limit cheaters to their pick of 5,000 characters. For legitimate users, just roll your counter over and re-issue characters. If a user notices, he's likely a cheater.

The software needs a license key which is can prove it owns without disclosing it. So that needs to be a public key of some kind. The combination of the license public key and a number in a limited range should be the PRNG's seed.

So, in sum:

1. When the software is licensed, issue a public/private keypair to the software. Sign the public key with the licensing private key.

2. To roll a character, combine a number from 0 to 5,000 (or whatever cap you choose) with the public key and use this to seed the PRNG. Sign the public key and the random number with the private key and combine that with the license signature.

3. To verify a character, use these steps:

A) Confirm that the signature of the software's key is valid using the licensing public key.

B) Confirm that the signature of the licensee's public key and index is valid using the software's key.

C) Roll the character using the index and licensee's public key and make sure the stats match.

That will limit each licensee to 5,000 characters.

-
I think the issue with a fixed limit is that it will be literally impossible for certain players to roll "perfect" characters, and I don't want to make that literally impossible, just as unlikely as the game intended. –  Joe Z. Jan 19 '13 at 4:45
I think that's a distinction without an actual difference. If it doesn't happen, what difference does it make if it didn't happen because it was impossible or because it was unlikely? If I die without having won the lottery, does it matter to me that it wasn't impossible? –  David Schwartz Jan 19 '13 at 6:35
A colleague of mine at the University of Waterloo suggested this same system about a year ago. I presented him with the same concern, and he gave me the same response. –  Joe Z. Jan 19 '13 at 13:39