Keyhotee Keychain Usage

When a user initially creates a profile, a keychain is created that can be used to generate a hierarchical set of public/private extended key pairs. Extended key pairs have the property of being able to generate child extended key pairs.

The user's keychain contains a top-level extended_private_key that can be regenerated from the user's profile information (name, etc) and his brainwallet password. This top-level key will then be used to create a separate extended_private_key for each identity created by the user (by calling keychain.get_identity_key(keyhoteeID). This allows these keys to also be regenerated in a new profile (assuming the user creates the same keyhoteeIDs (KHIDs) for identities in his new profile). An identity key can be used to generate "account keys" that allow for enhanced privacy exchanges with another authorized keyhoteeID (one account key is created per authorized KHID). Each time a transaction is performed between two mutually authorized KHIDs, a sequence of keys is generated to enable a transfer from multiple sending keys of one KHID to receiving keys of the other KHID. This tree of extended keys looks like this:

MasterKey (generated at profile creation, stored in keychain object)
  KeyhoteeIdentity1Key (created when user creates a new Identity. What about public-key only identities?)
    Identity1Account1Key (public part of this key sent to first authorized KeyhoteeID)
      Identity1Account1Trx1 (initial transaction key generated at authorization time)
        Identity1Account1Trx1Address1 (1 or more keys used for the transaction)
        Identity1Account1Trx1Address2 (multiple keys are used if 2 or more input addresses are required)
        ...
      Identity1Account1Trx2 (created after 1st transaction between Identity1 and KHID tied to Account1)
      Identity1Account1Trx3 (created after 2st transaction between Identity1 and KHID tied to Account1)
      ...
    Identity1Account2Key (public part of this key sent to second authorized KeyhoteeID)
  KeyhoteeIdentity2Key
    Identity2Account1Key
    ...

Note that it's not possible to regenerate the account keys exchanged by users during contact authorization with the current method of generating account keys employed by the keychain(using wallet_index), because wallet indexes will generally change when recreating a profile.

We could possibly support regeneration of account keys using the authorized contact's keyhoteeId instead of the wallet index. This seems desirable since full regeneration of the transaction keys should be possible by analyzing the blockchains on which the users performed transactions and incrementing an associated internal counter to generate each new transaction key. Without this feature, these address level private keys would be lost when creating a new profile.

Update: spoke with Bytemaster, and he wants to go ahead with using the wallet_index, with his reasoning being that users wouldn't always know the keyhoteeIDs of their contacts anyways (and we would still have to deal with the public-key only contacts, where they are much more unlikely to be able to remember the public key).

Our eventual method for recovering the private keys in the event of a loss of the profile using the wallet_index method will be to use a brute force search of integers starting from 0 up to some reasonable maximum value (user could specify approximate number of contacts in his old profile, for example). This should basically be workable, since we start wallet_indexes from 0 and increment upwards.