The silent GUID is used for identification if there exists one. If there doesn't exist one, it is generated and stored to silent.dat. When the player gets a new silent GUID it is not yet recognized by the server. Then the server uses the PB GUID(etkey) if, there exists one, to search it's database for a match. If a match is found, the database record is linked with the new silent GUID. If there already was a silent GUID for that record, the change of silent GUID is written to the server log. This was made so that the transition from PB GUIDs would work the easiest way. It doesn't work the same if your PB GUID changes. The server database is made to keep both PB and silent GUIDs as individually unique. But players are identified by their silent GUIDs if there exists a record for it and the PB GUID is ignored in such case. I don't remember the algorithm for generating the real etkeys, but it might have something related to time. So for that reason it is good to get the keys from etkey.org so that they don't clash. Silent keys are made of hashed UUIDs provided by the platform, which are supposed to be unique. These are hashed also before sending to the server so that they don't match the stored value in silent.dat. For more information of the PB GUIDs, you might find some from the Luigi Auriemmas website. I don't really know where to find the real algorithm if it's not there anywhere. It might be somewhere embedded in some thread about the matter for example at splashdamage or splatterladder.