ClientIdRequest

Answers ServerVerificationEvent. It opens a three-step proof that you hold a private key, and the value it carries is a COMMITMENT - not an identifier, not something you own, and not something you can look up.

WHEN TO SEND IT

IMMEDIATELY, ONCE PER POLL, AND FROM NOWHERE ELSE. The client builds it in exactly one place - the handler for the poll - and answers unconditionally. It reads NOTHING out of the poll; the event's arrival is the entire instruction.

IT COMES EARLY. The poll can arrive on the bare connection, before the ticket exchange has finished, so this is one of the first things you ever send. Do not gate it on being logged in.

WHAT TO PUT IN IT

k  = a fresh 400-bit random integer   (50 random bytes, read little-endian)
id = decimal string of  G^k mod P

P and G are not secret, not negotiated and not per-session: the client hard-codes the RFC 2409 768-bit MODP group - "Oakley group 1" - which is a published constant, with G = 2 and Q = (P - 1) / 2. The whole handshake lives in that one group.

KEEP k. IT IS THE POINT OF THIS MESSAGE. Only G^k travels; k itself never does, and ClientChallengeProofRequest cannot be computed without it. Generate it here, store it, and use that exact value later.

NEVER REUSE k. A Schnorr nonce answered against two different challenges leaks the private key by simple arithmetic - this is the classic way these schemes are broken. The real client draws a new one on every poll and overwrites the old, so a second poll silently invalidates any proof you had not yet sent. Recompute, do not cache.

USE A REAL RANDOM SOURCE. The client uses a cryptographic generator. A predictable k is as bad as a reused one.

IT IS A CORRELATED REQUEST. The client allocates an envelope uid for it, which most of the protocol does not - all three messages of this handshake do.

The value is derived, never stored: it differs on every poll and on every run.

IT STAYS ON THE MAIN CONNECTION. While a fight-server transfer has a second socket open (see IdentificationRequest) the client routes outbound traffic by message type, and all three verification requests are pinned to the FIRST connection. Gameplay traffic is what moves to the fight server, not this.

THE COMPLETE ALGORITHM IS ON ONE PAGE. Constants, both exponents, both branches, what the server checks and the ways an implementation goes wrong are written out in full under ClientChallengeProofRequest. Read that before implementing any part of this exchange.