There has been some discussion on the forums about the problem of trying to keep one's account name on all the different DACs that are going to be coming out. New DACs can snapshot the names on an older DAC they split off from (or Keyhotee founder IDs), but I think this is a really inelegant solution that doesn't actually fully addresses the problem, as I have discussed at
https://bitsharestalk.org/index.php?topic=6420.msg85558#msg85558.
This is my proposal on how to deal with this issue. But first, I want to discuss how I understand names in the BitShares ecosystem. BitShares names are like email addresses (I believe bytemaster has already used the email metaphor to explain the naming system). An email address has two parts, the handle and the domain, e.g. james@example.com. The handle james is not universally unique; there can be a james@gmail.com, james@yahoo.com, etc. However, it is unique to a domain, and this is enforced by the mail server located by that domain. The mail server may have an IP address like 10.1.2.3, and a domain name like example.com pointing to that IP address. We have an analogous situation with BitShares: the mail server is now the DAC and the handle is the registered name on that particular DAC. The analogue to the IP address is the information necessary for universally identifying a particular instance of a DAC, such as the hash of the genesis block of a DAC. Regular people shouldn't have to deal with the hash or IP address. Instead, in the case of email, they use domain names. I think that the analogue of the domain name in BitShares is a local alias for a DAC that the client recognizes. For example "btsx" could be used to represent the particular BitShares X DAC that the client is configured to connect to. Meaning my BitShares X account could be referred to on my local machine by the name "arhag@btsx" for example. The same client might be configured to associate "namespaces" to the BitShares Namespaces/DNS/.p2p DAC (toast, which is the official name?) which the client could also connect to, or alternatively the client could send RPC calls to another client running on the user's machine that connects to the BitShares Namespaces network. These aliases are local to the client (not necessary universally recognized domain names, but by convention all clients might use the same names). You can think of them as manually setting hostnames (to continue the email analogy). I don't think manual hostnames are a burden in the BitShares ecosystem like they are for the web, because in the case of the web, your one browser can navigate to a web page located at any domain name, or your one email client can send an email to an email address at any domain name, but in the case of BitShares, you effectively need new software to run on your computer for every new DAC (or "domain") you want to be able to access.
So how does all of that deal with the unique name problem? To answer that I need to discuss how owner keys would be created for accounts in this system. By the way, I don't know the exact details of how the BitShares toolkit currently deterministically generates the owner key of an account from the wallet root key. I imagine it is similar to what I am going to discuss, but I am going to describe how I envision it should work. Each account created within a wallet would have a specific local index associated with it. That index (which in my system could be a string) along with the wallet root key determines the owner key of the account (something like WALLET_ROOT_KEY.hardened_child(ACCOUNT_INDEX) => ACCOUNT_OWNER_PRIVATE_KEY). The local index could by default be automatically set to an incrementing counter (increments each time a new account is created). To universally identify an account on any BitShares DAC, one only needs the public key corresponding to the private key that is generated purely from WALLET_ROOT_KEY and ACCOUNT_INDEX.
To make this more concrete, imagine a user James. James created a new wallet on BitShares X, and then created three accounts on that wallet. The first two accounts (jim and internetpseudonym) were created with default settings and then registered. This means the account jim was created with an owner key deterministically generated from WALLET_ROOT_KEY using the index 1, and internetpseudonym was generated using index 2. James then created a third account on the same wallet using the explicitly defined index "secretagent-2j29d94jd3s0" and was able to register it on the blockchain with the name agent007. If James now lost his hard drive and the only thing he backed up was WALLET_ROOT_KEY, his client would automatically be able to recover the two registered accounts jim and internetpseudonym, but it would not be able to automatically recovery his third registered account agent007 (this provides plausible deniability by the way!). James would have to remember and explicitly enter "secretagent-2j29d94jd3s0" into his client to recover the agent007 account and all of its funds.
James now downloads the client for the brand new BitShares Namespaces DAC. He of course wants to transfer over his accounts from BitShares X. So he imports the BitShares X wallet (or more precisely has the client extract the WALLET_ROOT_KEY and generated a new wallet with that key). The client could also look through all local accounts and their indices in the BitShares X wallet and use that to automatically set up the corresponding accounts in the new DAC. But if the client did not automatically import the wallet but nevertheless used the same WALLET_ROOT_KEY, it would still generate accounts on the new DAC with the same owner key as the corresponding account on the BitShares X DAC. By corresponding account I mean the account with the same index. So, if James creates a brand new default account on that wallet (so it has the default index 1) it would actually be an account with the same owner key as jim@btsx. And, if James decided to create a new account on that wallet using the explicit index "secretagent-2j29d94jd3s0" on BitShares Namespaces, it would create an account with the same owner key as agent007@btsx. If that account was registered on the BitShares Namespaces DAC under a different name, say jbond, outside parties would be able to associate the name jbond@namespaces to agent007@btsx because they have the same owner key. This is the link that can tie the different names of the same conceptual account on different DACs together.
So, lets say James wants to register the first account (index 1) on BitShares Namespaces blockchain. Unfortunately, jim is already taken. So he instead registers that account under james. Now james@namespaces is linked with jim@btsx. If Bob wants to transfer ownership of his domain name to James, but only has his BTSX account name (jim), Bob now has a way of finding out what name James uses on BitShares Namespaces without needing to talk to him. A lookup of jim on BitShares X can give the account's owner key. If there is a match for that owner key on BitShares Namespaces, then the corresponding account (james) must be the registered account that James uses. And so Bob can send the domain to james. This entire process can be automated by the clients. Bob should just be able to type jim@btsx in the to field and have his client automatically resolve who to send the domain name to in the background (or give an error if the user isn't registered on the relevant DACs).
Then, there is a final step to make all of this incredibly convenient and to, for example, be able to just give one universally unique name on a business card. We must develop a social consensus around which DAC everyone agrees to identify themselves with. My suggestion is that we use the upcoming BitShares Namespaces DAC for this purpose. I propose that by default every BitShares handle not further qualified with an @dacname should refer to the registered name on the BitShares Namespaces DAC. That means if someone wanted to send money to James in BitShares X but they only knew the BitShares X name (jim), they would have to send the money to "jim@btsx" (the @btsx would need to be explicit). If they just sent the money to "jim", it would instead be sent to jim@namespaces, who may not necessarily be James. The typical way this would be used, however, is for everyone to use the Namespaces DAC registered name within all DAC clients. So, the person sending money to James would learn that his Namespaces handle is james and would simply put "james" in the to field (although the explicit "james@namespaces" would be appropriate as well). If someone else wants to vote for James as a delegate on the Music DAC (on which James has registered the name jimmy@music), they would still put "james" in the to field of the Music DAC client (the system would automatically resolve james -> james@namespaces -> unique owner key -> jimmy@music). If this social consensus is followed, it becomes irrelevant what any of your registered names are except for the name registered on the BitShares Namespaces DAC. That name then becomes your universally unique name.
Topic: Using the same name on all DACs (Read 1347 times)
