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.
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.