Author Topic: Transferable name is a big mistake. It will be clear soon or later.  (Read 2896 times)

0 Members and 1 Guest are viewing this topic.

Offline theoretical

It strikes me that the best way for a blockchain to "import" notions involving the real world, like "this key belongs to this real-world person," is an oracle (ID provider) approach (an oracle is an entity that answers difficult questions, in this case an entity that answers questions about the real world for the benefit of the blockchain).

We can flag an account as being "this ID provider knows who this person is" by setting the account owner to a 2-of-2 multisig of the user and the identity provider.  The ID provider's terms can specify they won't allow the changing of the account's active key to any other real-world person.  The ID provider cannot disable the account, change the active/owner authority, or take the user's funds (unless they secure the cooperation of the user or obtain the user's private keys).

In other words, we shouldn't try to implement the notion of "this account is not transferrable between real-world persons" by saying "the keys for this account cannot be changed."  Instead, we should implement the notion of "this account is not transferrable between real-world persons" by allowing an account holder Alice to make a blockchain-enforced pledge of the form "I, Alice, will not change this account's keys without the consent of my ID verifier, Vera;" and Vera uses peoples' trust based on her real-world reputation [1] to make an off-blockchain pledge of the form "I, Vera, will not allow an account to change its keys in a way that will result in the transfer of the account from one real-world person to another."

The question Vera is answering for the blockchain is whether a proposed key change is legitimate (Alice is trying to recover after her keys were lost or hacked) or forbidden (Alice is trying to transfer the account to another real-world person, which would violate her pledge).  If it's legit, Vera signs and the change occurs; if it's forbidden, Vera refuses to sign and the change cannot happen.

NB since this is a 2-of-2 multisig, Vera has zero power to change the account unless Alice agrees with the change.  Vera's only power is the ability to veto owner/active key changes for the account.

This is all supported by the chain itself already, but there needs to be some standardization (e.g. it seems reasonable to allow Vera to attach a custom transaction to attach an annotation to an account specifying a purely informational, non-blockchain-enforced document expressing the circumstances under which Vera will allow a key change; the placement and formatting of the annotation need to be standardized).  And of course UI work to express these semantics and annotations to the user.

[1] Vera's real-world reputation might include telling everyone her real-world identity; people will be more likely to trust Vera if they know she's findable and prosecutable by the meatspace legal system in case she engages in fraud.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline theoretical

There are two conflicting requirements here:

  • We want to be able to support the user who says -- "I think my owner key might have been stolen, but I haven't been hacked yet -- what can I do to protect myself?"
  • We want to be able to assure people that the mapping of a real-world person / company to a username is immutable (can never be changed)

BitShares 0.x tries to implement the second requirement by making the name-to-key mapping immutable.  It hurts the user in the first requirement.  It makes our PKI security weaker because key revocation (an important part of any PKI) is impossible.

I'm not trying to take sides here.  I suspect that the reason we're having this debate is because the requirements we want the system to satisfy have not yet been articulated precisely enough for the answer to be clear.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline hadrian

  • Sr. Member
  • ****
  • Posts: 467
    • View Profile
  • BitShares: hadrian
This quote is from a post on a different thread.
It's similar to what bytemaster said above, but also mentions how the ability to change keys is also very important to the private individual if they are inclined to keep their account name

Quote
The important part of transferable account names is having the ability to change the keys associated with the name.
If BitShares is going to be widely adopted, having this ability is almost essential. People or businesses will need to keep an account name, and to build their business or reputation upon it. This has major security concerns, because in the real world people have problems obeying 'best practice'. We all know that not everyone can keep all information secure all of the time.

The ability to change the keys associated with an account is a massive benefit because it allows this concern to be significantly mitigated. If a member of staff has access to the keys, then they leave the company, the company can just change the keys. Likewise for private individuals who realize they didn't follow best practices, or who find malware on their computer...et cetera

I will certainly be changing my keys, once my account is migrated to 2.0, because I'm not sure that my keys are 100% secure, and I want to keep my account name. (I'm very please with the setup for easier and more functional security features in 2.0 by the way)

edit:
I would rather get rid of account names entirely than keep them non-transferable.

I agree with arhag. There's no question in my mind that having account names without the ability to change the keys would be disastrous. This is solely down to the security issues for me.
« Last Edit: June 18, 2015, 09:58:00 pm by hadrian »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

I believe BM wanted the requirement that corporate account names can still be recovered and used even after the owner key is compromised. He can explain the reasoning more.

I understand this requirement. But it seems impossible unless you use a *owner-owner key* or multi-sig to change your *owner key*.
By that means the *owner-owner key* or multi-sig will be the new **owner key** In essence.

However it is different with transferable account name.
Hacker always can transfer name to himself if they get owner key, or owner-owner key,or multi-sig etc, and then corporate account cannot be recovered. I can't see how transferable account name feature resolved the requirement.

As a company, I want one name that I can change the keys for as different management comes through.   I want the ability to transfer the brand.   

If the brand is "stolen" then that will require them to create a new brand and get people to stop using the old brand.   It is the exact same result whether or not the owner key can be changed.  Once it is compromised it might as well be transferred.  At least if it is transferred then it is possible to alert everyone that it is under "new management" and to pay extra close attention. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline logxing

I believe BM wanted the requirement that corporate account names can still be recovered and used even after the owner key is compromised. He can explain the reasoning more.

I understand this requirement. But it seems impossible unless you use a *owner-owner key* or multi-sig to change your *owner key*.
By that means the *owner-owner key* or multi-sig will be the new **owner key** In essence.

However it is different with transferable account name.
Hacker always can transfer name to himself if they get owner key, or owner-owner key,or multi-sig etc, and then corporate account cannot be recovered. I can't see how transferable account name feature resolved the requirement.
BTS Account:logxing

Offline logxing

Ahh ... and .. back 6 months people complained about not being able to transfer accounts ..
I always think account name should not be transferable, definitly.
BTS Account:logxing

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I would rather get rid of account names entirely than keep them non-transferable. But keeping transferable account names shouldn't be an issue if we design things right and teach users sensible practices.

tl;dr Just use account IDs for everything (especially for links on the internet and referring to identity in third-party databases). The only time account names should be used is to add a new contact to your address book that you were not able to add through better means such as trusted web links or mobile-to-mobile communication. The GUI shouldn't allow the user to do anything of value with an account unless they are first added to the address book (perhaps even added automatically to some obscure part of the address book because of some action where the smartphone is interacting with the real world, for example for POS payments). Adopting these practices should deal with the vast majority of the issues. What remains are edge cases dealing with what happens when a contact changes their account name after telling you their account name but before you have the opportunity to add them to your address book. Those cases can be handled through changes to the GUI of the client and proper education on how to use the client.


The first thing to realize is that if you want to allow account owners to be able to update all private keys associated with their account for security reasons, then it is impossible to prevent account names from being transferred. The current owner could just sign a transaction using the current owner key changing the owner key of the account to one specified by the buyer of the account name. Yes, all identity information would be transferred along with the account, but a name squatter buying valuable names for the purpose of later selling them isn't going to care about that. The security benefits of changing the owner key are very important that I would say it outweighs any other concerns about identity you may have when account name becomes transferable.

So once you accept that you cannot avoid allowing account names to be transferred, you might as well make it possible to transfer the account name without also transferring all the other identity information. In fact, there needs to be a clear separation between an identity and an account name. That brings me to my main point...

Your account name is not your identity! Your identity is your account which can be uniquely and immutably referred to by the account ID. This is the thing that can be stored in third-party databases, NOT the account name.

Now that is fine for computer databases, but human brains aren't good at remembering large numbers. So clearly people would prefer to instead remember a human readable account name over an account ID. How do we avoid the human error this can cause when we consider that the name of an account can change and the old name can belong to another account (meaning another identity)? The solution is for humans to not try to rely on their memory but rather rely on computer databases. The mapping between the human-understandable information describing an identity to a unique account ID should be local to each user. This is the information that will be stored as part of the wallet file (which is stored in the browser's local storage, but can also be exported and backed up elsewhere). In fact, I think it would be smart for the wallet hosts to provide a service where they store an encrypted version of the wallet file for the user and sync it as necessary to their clients. The point is that the mapping is local to each user and not global on the blockchain. This means that every user can specify the alias (and even picture and other information) that helps remind them who that contact in their address book really is. None of this requires any global blockchain name registration or management.

However, with all of that said, name registration on the blockchain is useful. Particularly, it is useful as a method to allow humans to add new contacts to their address book when the only way they are able to refer to the account is through a uniquely-identifying string/number that they are forced to remember. The context through which they came to know or meet this new contact may not have facilitated using better methods of adding the contact right then and there, such as direct mobile-to-mobile contact sharing or clicking on an add contact link from some trusted web source or even scanning a QR code with their smartphone that was presented to them in person by the contact. Perhaps they didn't have their smartphones or didn't have time to use them and the contact quickly shared the uniquely-identifying string/number before leaving. Perhaps this string/number was shared over a medium where the validity of the source could be readily verified thanks to biometric authentication or trust in the provider of the media, such as a well-known guest with recognizable voice on an audio podcast saying and even spelling her handle, a video podcast showing the respective handles of guests whose face people can recognize in the lower third overlaid when they are on camera, a presenter that people know displaying their handle in his slides during a live lecture, or just simply the new contact they meet telling them the handle in person. Now the number could just be the account ID or the string could be a sequence of dictionary words encoding the account ID (+ a checksum), in which case name registration is again not necessary. The problem is that since the user is not able to choose their account ID (and thus the deterministically derived string of words representing the ID either) it might still be difficult for humans to remember them (although the sequence of dictionary words encoding the account ID trick does get pretty close to being memorable). Also, from a vanity point of view, users may wish to have their own choice of the string that they present which will map to their account ID even if faulty memory wasn't that big of an issue. This leads us to registering globally unique account names on the blockchain and mapping them to account IDs.

So that is when all the various edge case problems come in that need to be dealt with. If a person registered the account name once and never changed it, there would be no problem other than typos and misspellings which could be solved by also remembering, sharing, and including a small easy-to-remember number that acts as a checksum. And once a user adds a contact into their address book using their handle, their client should be designed to protect them from account name changes because it can remember the immutable account ID of the contact locally (and this local data should be backed up with the rest of the wallet). The tricky part is in the case where the contact changes their account name in between the time the contact veritably shared their original account name in a way that the user could access and the time the user added that contact using the original account name that they remembered. Even this is not an issue if the old contact name is not transferred to or claimed by any other account before the time the user adds the contact since the client would respond to the user that the account name is not currently being used and could show the past history of ownership of that name. What we really want to avoid is another account adopting the old name before the user adds the contact using the old name causing the user to add this other account instead of the original account. But the blockchain tracks when account names are created, moved, revoked, and adopted, so this information history could be made available to the user's client. If the account name provided had recently (this could be a wallet adjustable setting but a default of two weeks seems like a good idea) changed ownership, the client can show massive warnings to the user, provide detail, and require further action before proceeding. The information provided would allow the user to determine which of the accounts they meant to add depending on when they got the information about the account name. This is an edge case, so usually these warnings would never appear since the account name would have most likely not been recently moved. As long as the user is not adding an account name from a very old source, they should be fine. If they do want to add an account name from an old source (more than 2 weeks old for example), the client could provide an advanced interface allowing them to specify a date to determine the ID of the account that owned that name at the date. Since I believe the use case for adding contacts using their account name should mostly be for in person interactions where smartphone contact transfer was not applicable, or live radio or TV, I don't think this will be a problem. If someone is consuming old recorded media, it is probably a better idea to not trust that handle and instead try to find the handle of the person they want to add from a more recent source just to be safe. And in the case of consuming the handle from an online source, the best practice would be for the website to just include links that point to the account IDs directly to just avoid these problems.
« Last Edit: June 18, 2015, 04:47:26 pm by arhag »

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Ahh ... and .. back 6 months people complained about not being able to transfer accounts ..

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I dont see why it should hold accountname <-> identity ..

Also, where does it say that DNS will use the SAME namespace?

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
I don't see any disadvantage in this function.

Offline vikram

I believe BM wanted the requirement that corporate account names can still be recovered and used even after the owner key is compromised. He can explain the reasoning more.

Offline logxing

Transferable account name will ruin the Identity system in BTS.

Yes you can clear all connection info about the name when it was be transferred. But you cannot clear the  INFO store in people's brain, or in 3rd party's database.This will be a big chaos ID world. And you will see many many claim about "Human error".

(BTW, many quality names were hold by only a few people, very few.)

Domain transfers is OK. But Identity is different. Identity is more personal and intuitive. Especially in BTS, we use account to receive fund, and we can do more important things in the future.A digit-Identity, just like your identification paper, should not be transferable. That's why it called "Identity".

Your identity is NOT ONLY enforcement of right(sign by your private key), BUT ALSO how the other people remember you.

Transferable name is a big mistake. It will be clear soon or later.
It is not about freedom, or technical demonstration, or what the other crypto done.
It is about a reasonable Identity System design.

Identity System is very important feature of BitShares. BitShares is a very serious Finance Platform, right?
Transferable name feature is a unnecessary hazard. The fee is meaningless if you consider the risk.

I beg DEV team review this topic again prudently.
BTS Account:logxing