Ah, I think I see the problem.
Rednet works by sending specially formatted messages through modems, which destination systems receive as "modem_message" events in their event queue (same as if you
transmit directly through modems, without using rednet at all). When a given system boots, a special function called
rednet.run() is started in parallel with the shell. One of its jobs is to look for modem_message events, and if it finds they were transmitted via
rednet.send(), it
queues corresponding rednet_message events (which you can either pull
directly, or via
rednet.receive()). It's also rednet.run() which responds to lookup requests.
ComputerCraft 1.6 added a "repeat" script to each system, which waits for incoming rednet messages and re-sends them through all available modems. The purpose of this is to make it easier to extend the range of networks - these days, with a single computer running that script through an Ender Modem, you've got pretty much the whole Minecraft server covered.
The introduction of this script created a bit of a problem in that it became possible for multiple modem_message events to be received for each message sent via rednet. To counter this, Dan added an extra bit of data to each modem_message associated with rednet - a random number. If two modem_messages with the same random number are received within half a minute, rednet.run() will not create a corresponding rednet_message, assuming them to be duplicate copies.
The odds of erroneous collisions are pretty low under normal circumstances, but your "unfoldkey" functions complicate matters by messing with the random number seed. More specifically, they keep resetting it back to a particular static value, which makes the odds of rednet collisions "near certain"!
Change these lines:
math.randomseed(math.random())
… so that the seed is a bit more unpredictable:
math.randomseed(os.clock())
math.random() isn't suitable as a seed in this instance because you've just set a seed of "keyhash" (which is the same every time - you read it from a file) and then rolled 32 values. The 33rd value, the one you use to set the new seed, is always going to be the same. The system clock is nearly certain to be different every time you check it, however.
The thing I'm scratching my head over is that if this is the problem - and I can't really see any other alternatives - it'd be the seed of the
client system at fault, not the seed of the server. Hrm. Do systems share seeds? Might have to look into that one… Maybe you're simply running similar code on the client system…?