> My point is precisely that this property isn't critical for identity.
I don't know what you mean. I think you'll agree that it would be undesirable for me to insist being called by the same name as one of my coworkers, for example. Name collisions are definitely a problem for identifying people in practice.
> And no, blockchains aren't trustless, at least not in the sense in which trustless is generally used. In the case of Bitcoin, you have to trust that the miners will behave in a certain way. There are no mathematical guarantees.
We might have different meanings for "trustless." Can you give an example of a non-trivial PKI system or protocol that you consider "trustless?"
I consider the blockchain to be "trustless" because it's extremely hard to make a convincing forgery of one, and because I can verify with high probability that the blockchain I have is the "right" blockchain. I can verify that a blockchain is well-formed, I can calculate a highly-probable lower bound on the number of compute cycles needed to generate it, and I can compare this lower bound to an expected value based on my external knowledge of electricity costs, semiconductor costs, history of Bitcoin's compute capacity, and so on. The only thing I need to assume is that the blockchain I received was generated by a set of peers who spent the majority of their combined cumulative compute power to mine it honestly. However, I'd argue that this assumption holds true in practice, because the amount of compute power an adversary would need to use to generate a valid but wrong blockchain is enormous and costly (it may very well be cheaper for the adversary to achieve its goals via some other route).
First of all, you can insist all you want, it won't make it so, people will call you what they want. Second, I can insist on being called "Warren Buffet", and people may even humor
me, but that won't let me sign checks from his bank account, or give commencement speeches.
Regarding trustlesness: the onion hidden service model (domain is hash of key) is trustless in the sense that, according to very strong mathematical conjectures, it would require astronomical power to break.
There are no mathematical guarantees at play at all in Bitcoin. You're assuming that miners are solely interested in earning rewards and not in bringing down the chain. You're assuming they're not colluding with each other.
And no, breaking bitcoin doesn't entail spending hundreds of millions building up mining capability, that is complete wishful thinking. It entails spending a couple millions to kidnap the families of a few mining pool operators.
> First of all, you can insist all you want, it won't make it so, people will call you what they want. Second, I can insist on being called "Warren Buffet", and people may even humor me, but that won't let me sign checks from his bank account, or give commencement speeches.
You've proven my point that name collisions are undesirable.
> Regarding trustlesness: the onion hidden service model (domain is hash of key) is trustless in the sense that, according to very strong mathematical conjectures, it would require astronomical power to break.
I'd say this is a bad example of "trustless." As an adversary, I don't have to break your onion service's private key to break the security of the system. All I have to do is trick users into accepting the wrong public key. The user must therefore trust that the public key hash (s)he learns is the "right" public key hash.
The choice of names becomes important when you consider how a user learns the legitimate public key hash, especially if you consider the problem from the perspective of a non-CS user. Name memorability is important for discovery. Two public key hashes are distinguishable, but they look like gibberish and are hard to memorize, meaning that it's hard for users to propagate their knowledge of the right public key hash. However, "bankofamerica.com" is memorable, is easily conveyed in verbal, written, and electronic communication, and is easily distinguished from "bank0famer1ca.com".
As mentioned in another comment, the problem I'm trying to solve is not proving whether or not the name owner actually is Bank of America. I'm only trying to bind human-meaningful names to public keys in a decentralized but hard-to-break manner.
> There are no mathematical guarantees at play at all in Bitcoin. You're assuming that miners are solely interested in earning rewards and not in bringing down the chain. You're assuming they're not colluding with each other.
The blockchain itself uses strong mathematical conjectures (i.e. the hardness of calculating a partial preimage of a double-SHA256) to place a huge lower bound on how much CPU was used to produce it. As explained earlier, this is important because it's also the lower bound for an adversary to overcome to create a plausible blockchain with the wrong data.
> And no, breaking bitcoin doesn't entail spending hundreds of millions building up mining capability, that is complete wishful thinking. It entails spending a couple millions to kidnap the families of a few mining pool operators.
Miners can and will switch pools if a pool operator starts to misbehave, so kidnapping all the pool operators' families won't gain you much. Moreover, the amount of work you'd have to do to retroactively alter the transaction history to change my transaction's (name, pubkey) is bound below by the amount of work to mine each block between my transaction and the current block (you'd have to re-mine the transactions faster than the rest of the network; otherwise you'd never catch up to the longest fork). Kidnapping pool operators won't help you recalculate these partial double-SHA256 preimages.
> You've proven my point that name collisions are undesirable.
But there is no collision. In the example I'm making, the people chose to humor me, they chose to introduce a collision because they always have context information.
> I'd say this is a bad example of "trustless." As an adversary, I don't have to break your onion service's private key to break the security of the system. All I have to do is trick users into accepting the wrong public key. The user must therefore trust that the public key hash (s)he learns is the "right" public key hash.
How do you learn about the website in the first place? Most likely online.
> I'm only trying to bind human-meaningful names to public keys in a decentralized but hard-to-break manner.
Yes, I get that. The point is that there's not much of a point in doing that.
> Miners can and will switch pools if a pool operator starts to misbehave
That depends. They may be enticed to follow the attack chain.
And by the way, even if you really, really insist on binding human meaningful names to keys, all you really need is a Haber Stornetta timestamping service. No need to bother with proof of publication, which is where the blockchain gets most of its bloat from.
> But there is no collision. In the example I'm making, the people chose to humor me, they chose to introduce a collision because they always have context information.
Collisions are allowed precisely when other parties humor you. Warren Buffet's bank did not do so; it resolved the collision. I'll bet that you can come up with many examples where people will not humor you if you introduce yourself as Warren Buffet, so I'll not belabor this point further.
> How do you learn about the website in the first place? Most likely online.
Actually, my parents told me.
Look, if you'd rather assign non-human-meaningful names to principals instead of human-meaningful ones when the security of one approach versus the other are otherwise sufficient, then please don't let me get in your way. However, I think your preference is in the minority, and I think there is plenty of historical data on things like domain name prices that backs my opinion up.
> And by the way, even if you really, really insist on binding human meaningful names to keys, all you really need is a Haber Stornetta timestamping service. No need to bother with proof of publication, which is where the blockchain gets most of its bloat from.
That's effectively what the blockchain already does, no? It provides a hash-linked list of all blocks, which in turn must contain a set of well-formed linked lists of of signed transactions consistent with Bitcoin's protocol rules for each key with a non-zero balance. The proof-of-work scheme stops weak adversaries from doing the equivalent of (1) publishing an adversary-chosen hash in the newspaper, and (2) replacing some of the archived copies of the library with different ones with invalid hashes, all in order to trick you into trusting the wrong documents. Also, if it wanted to do so, a newspaper could publish every kth block's hash to help lend credibility to the longest chain.
Personally, I don't agree with your assumption. It is totally fine for 2 people to have the same globally recognized name because the people who need to differentiate between them will spontaneously invent a system to do so.
In Japan nobody has middle names and family names in some areas are very common. For example, where I live Suzuki is ridiculously popular. At the school I taught at, 10 of the 80 teachers had the last name Suzuki and 3 of them had the same first name. It was absolutely not a problem.
These teachers responded to many names. Sometimes their first name, sometimes their last name, sometimes their home room class number and their last name. The name that was used depended on context. There was absolutely no reason to have a globally unique name for them. Their family called them something, their friends called them something else, their colleagues called them something else, their students called them something else.
The important part is that the person interacting with someone has a distinguishable name for that person. However, they do not need to share that name. I don't need to know that my colleague's wife calls him Pooky, while I call him Tarou, while his students call him Mr. Suzuki (if they can even remember his name at all -- quite a lot of the students will just call him "teacher").
This is also true of computer systems, from my experience. You need a globally identifiable identity (like an SSH key), but you do not need a globally identifiable name. The people who interact with the identity can choose any name they wish. The name is not important.
Sometimes you have 2 or more people who know the same person and want to reference them. As long as they have a globally recognizable identity, then it's fine. So if person A says "Pooky (who controls ssh key 1234) is a very kind person", I can easily identify the person that they are talking about (or verify that I don't know that person). My determination of whether the person is kind or not will depend on how much I trust person A.
As the other poster mentioned, in virtually every case, web of trust, and nick names are exactly what you want. The only time you need a globally identifiable name is if you are interacting with someone that you have never had any dealings with before (and none of your acquaintances have had any dealings with before) and you want to be assured that they are who they say they are. But in this case there is still a gap -- you will need some kind of authority to vouch for their identity (like a government with a passport number or something like that). A block chain will not do that for you.
Like the other poster, I can see no utility in this. It's technologically interesting, but there are better ways to disambiguate names.
Edit: Reading further in the comments, key revocation is an interesting problem which I hadn't considered. I can see a use for a ledger in that case.
> The important part is that the person interacting with someone has a distinguishable name for that person.
I think your example actually proves my point. In the limit, how does one tell apart all of the people with the name Tarou Suzuki's? Contextual hints aren't always useful to the identifying party (in the limit, none are), so ultimately a globally unique name such as a passport number or an SSH key must be used instead.
We seem to disagree on two points: on the utility of a globally-unique name being human-meaningful, and on whether or not these names need to be issued by a centralized trusted party. Regarding the former, I think there are many obvious cases where a globally-unique but human-meaningful name is preferred to a globally-unique but non-human-meaningful name. Examples include DNS name versus IP address, and Twitter handle versus user ID. Giving a user a globally-unique human-meaningful name already has proven applications for things like SSO (e.g. Facebook Connect), and has hypothetical benefits like allowing the user to share information across services seamlessly. This article makes the case for a decentralized implementation. Am I to understand that you believe this has no utility?
Regarding the second point, if you take a simple DNS-like policy of "first person to claim a name gets it, and has to renew it periodically to keep it", you can absolutely use a blockchain to vouch for bindings between human-meaningful names and humans. It's no different than binding an address to an unspent output in a transaction. As mentioned above, the caveat is that you have to trust that the peers mining the blockchain dedicate the majority of their cumulative computing power towards playing by the blockchain's rules, but I have argued that this isn't an unreasonable thing to do, due to the difficulty of creating a plausible but wrong blockchain. The reliance on a central party like a government isn't without its own issues, after all (even mundane ones, like sending the passport to the wrong address, or mistyping the owner's name).
I wholeheartedly agree that contextual clues and nick names are highly desirable. However, the fact that they don't always work means that we need a fall-back mechanism for identification. Why settle for a meaningless string of digits and characters, when it can be something easy to remember and meaningful to the owner?
I'll try to respond to this without writing a book ;-) It's hard because I think you are missing the point that the things you want are possible without the solution that is presented here. The other solutions are also simpler.
There are 2 scenarios. In the first scenario, I have a pseudonymous interaction with someone/something and I simply want to ensure that every time I interact with that person/thing it's the same one.
For example, if I am a store, I want to make sure that my repeat customer is actually the repeat customer. If I am talking on HN, I want to make sure that the jude- that I am talking to today is the same jude- that I talked to yesterday. I really don't care who that person is. I may also care that jude- is the same jude- (or some other name) on another system. Or perhaps I want to be alerted when that person is confusingly different.
All of those things can be done without a centralised ledger. They simply require a public key that is signed and distributed appropriately.
I will also add to this scenario the situation where you actually need to know the real identity of the pseudonymous entity (say if you are a bank). This requires a central authority who can verify the identity (this is required in every case), and that the central authority signs keys appropriately and makes those signatures available.
The other scenario is when I want to contact a specific entity and I don't trust any intermediary to give me the correct information. DNS is perhaps a decent example. I want to contact a IBM's web server and I don't know where they are. I don't necessarily trust the providers.
Now, I think you will agree that in the general case this is impossible. The best I can do is go there once without trusting it and then build up a relationship with that entity to the point that I trust it is the real IBM.
Unfortunately, the current tools do not even allow us to do that easily. However, you could imagine a system where if IBM wanted to change their DNS, they would have to sign the change and if I was a repeat user of their site, I would have their public key to verify the change. This part of the scenario is just like the pseudonymous one.
There isn't much we can do to actually verify that the DNS entry for IBM actually leads to IBM if we don't trust the DNS system, but we can at least monitor if the DNS entry has changed. That way if millions of people are happy and not complaining, we have some confidence that it is the real IBM.
This public ledger is useful (as I pointed out in my edit) if a key gets revoked (so if you meet the imposter after the key has been revoked, you can discover it). It is similarly useful if something has changed before you had a chance to contact it and get it's public key (essentially same scenario as key revocation).
However, even this scenario has simpler implementations than the one suggested.
Finally, you suggest that having a globally unique name is useful because it could be meaningful. What shall we call the 3 teachers who work in the same school and live in the same town and have the same name? Shall we call them Tarou Sukuki 1, 2 and 3?
There is a reason why IPV6 is so huge. We need a lot of addresses. We will not be able to make them all meaningful. You need a map, but that map will necessarily have to be of the 1->N and context based.
> In the first scenario, I have a pseudonymous interaction with someone/something and I simply want to ensure that every time I interact with that person/thing it's the same one.
> All of those things can be done without a centralised ledger. They simply require a public key that is signed and distributed appropriately.
Who signs and distributes the key, and why do you trust them to do so? This sounds a lot like the CA model, which I am trying to avoid using.
Even if you went without a CA and relied on TOFU semantics, using the blockchain to distribute your public key is still a better choice than sending it over the wire to each requester because (1) when creating my name/pubkey pair, I will notice very quickly if the (jude-, pubkey) record in the blockchain is wrong, and immediately claim a different username; (2) once (jude-, pubkey) is published in the blockchain, it is extremely hard to change, so our adversary can't send you a different public key if you're on the same blockchain as me; (3) it is extremely hard for an adversary to make a separate plausible blockchain with the wrong (jude-, pubkey) transaction, since that would require a tremendous amount of CPU time to calculate all the necessary partial double-SHA256 preimages in order to re-write the transaction history back to the block where I registered (jude-, pubkey).
> I will also add to this scenario the situation where you actually need to know the real identity of the pseudonymous entity (say if you are a bank). This requires a central authority who can verify the identity (this is required in every case), and that the central authority signs keys appropriately and makes those signatures available.
I think this is a different problem than what I was trying to solve. It sounds like you want to have a high degree of confidence that the DNS name "ibm.com" points to web servers belonging to the actual IBM, and not a squatter or phisher. If so, then I agree that a blockchain will not help you there. The problem I've been trying to solve is using my out-of-band knowledge that "ibm.com" is the name for IBM's servers to obtain IBM's public key, without having to trust DNS, a CA, or some other centralized entity. I apologize that this was not clear earlier.
> Shall we call them Tarou Sukuki 1, 2 and 3?
Why not let them choose their own globally-unique names, and use a first-to-claim policy to resolve collisions?
I don't know what you mean. I think you'll agree that it would be undesirable for me to insist being called by the same name as one of my coworkers, for example. Name collisions are definitely a problem for identifying people in practice.
> And no, blockchains aren't trustless, at least not in the sense in which trustless is generally used. In the case of Bitcoin, you have to trust that the miners will behave in a certain way. There are no mathematical guarantees.
We might have different meanings for "trustless." Can you give an example of a non-trivial PKI system or protocol that you consider "trustless?"
I consider the blockchain to be "trustless" because it's extremely hard to make a convincing forgery of one, and because I can verify with high probability that the blockchain I have is the "right" blockchain. I can verify that a blockchain is well-formed, I can calculate a highly-probable lower bound on the number of compute cycles needed to generate it, and I can compare this lower bound to an expected value based on my external knowledge of electricity costs, semiconductor costs, history of Bitcoin's compute capacity, and so on. The only thing I need to assume is that the blockchain I received was generated by a set of peers who spent the majority of their combined cumulative compute power to mine it honestly. However, I'd argue that this assumption holds true in practice, because the amount of compute power an adversary would need to use to generate a valid but wrong blockchain is enormous and costly (it may very well be cheaper for the adversary to achieve its goals via some other route).