Talk to me: niran@niran.org
Yes, they do. See this long list of failed altcoins.[1]
Minor cryptocurrencies can fail in some unexpected ways.[2] The classic 51% attack has happened in practice to several altcoins.[3] There's also a "burst mining" attack, which can happen automatically - a big mining pool's control system determines that it would be profitable to divert the pool to briefly mining some altcoins and get all the blocks for a while. Then the difficulty goes way up, and the big pool goes off to do something else. Now the difficulty is so high that no blocks get mined at all for a considerable period of time and transactions stall.
[1] https://bitcointalk.org/index.php?topic=588413.0 [2] http://www.ofnumbers.com/2014/06/03/thread-of-the-day-list-o... [3] https://maxminer.files.wordpress.com/2013/06/ftc_51attack.pd...
https://okturtles.com/ is the most successful of them so far. I am not a crypto expert (even less of a blockchain expert) but the code looks pretty good, and the ecosystem is pretty mature. It has 1) its own aux. DNS service which is tied to your key (somewhat like Tor routing via onion but with acceptable latency), 2) decentralized IdP via block chains, 3) a browser plugin, 4) a whole lot more (see the Github linked below.
From the article:
Update I’ve written a more-up-to-date technical overview of okTurtles, DNSChain, and Unblock.us. While the security model for DNSChain has improved, they are still misrepresenting the security parameters of their software.
I’m going to leave this up since it debunks what DNSChain was selling. I also think their resistance to outside security concerns is very troubling.
TL;DR
DNSChain erroneous claims to have passed a “peer review” process. However, its most important peers, Namecoin developers, have rejected it. This has been the reaction of every Namecoin developer who has evaluated the project (over four at this point). The project misrepresents its security model, its design is unfixable, it should not be used in any nonlocal capacity.
Can you please comment here (or set up a webpage anywhere), explaining the overall ideas and proposals?
If your idea of user-controlled identities is truly about something that users do possess (not just being provided), and you have any plan how to bring it to the world (without for users to need to install any software — that'd utterly fail — or do anything much besides clicking "log in as myself") — then I'm all for it.
___
¹) Although I do believe Persona screwed it badly, as identities weren't controlled by users there, but merely leased to them by third parties - I find the concept of "identity provider" to be very wrong.
Well, IANA does. Then, if it's a ccTLD, your NIR (controlled by your government) does. Then the registrar you've registered domain name with does. They all do lease it to you (although legal agreements sort of say you "own" it, it's not a true ownership), but in practice they can take away your identity at any time they see fit or forced to. Or impersonate you, without your consent or even knowledge. I think we've heard about enough domain name seizures to not assume they're something owned. And an identity that can be seized or revoked is something that's just not right.
I really want an identity system without need to trust any third parties to work. I walk in a store, I say "hi", they say "hi", and we're good. Just like it used to be with usernames and passwords, but without obvious issues passwords have. Notaries are absolutely useful, but they should assert identities ("yep, we know this dud, he's cool"), not provide them.
Users will have to install something because browsers have no key signing mechanism. If you manage keys in a web page, that web page can access your keys. You'll need an extension or an app to manage keys for you.
This approach sounds like a stretch, right? No website is going to use an authentication mechanism that requires a separate install. If that were the initial use case for this, I would agree. The real use for these identities is within decentralized applications. These apps don't run on servers and don't force you to use middlemen when you interact with other people. Decentralized apps don't shut down. They don't care where you live. They connect you with other people on the planet that want to connect with you to trade, communicate, or interact in any way you want. The two of you choose your own rules, not those of the companies or governments that stand between you.
This is not a replacement for Persona, OpenID or "Log in with Google/Facebook/Twitter" buttons, which was what I hoped to see. And I'm not even sure how this is better than my PGP keypair (which is something way more widely recognized than Ethereum).
Is there any skilled and powerful necromancer out there that can revive and reanimate W3C WebID committee?
Like, compared to publishing a public key. Simplicity doesn't seem to be an answer.
What does a blockchain add to this?
PGP key servers can refuse to relay your revocation. Blockchains are censorship-resistant. They also let you define your own authentication, revocation and backup logic.
PGP identities are keys. Blockchain identities are programs.
Specifically, a miner can refuse to encode your transaction just as much as your first PGP server can refuse to accept the sent key. (PGP actually has a strong advantage here, since it's easy to push your revocation to all the servers on your own, immediately, but you yourself are extremely unlikely to mine a block with your own transaction, unless the network is otherwise broken security-wise.) So the primary thing to worry about is a server that refuses to provide information on the revocation, once it has hit the shared database. But that can be solved by just having cryptographic monotonicity, that no transactions can be removed once encoded; you don't need the blockchain's specific power to order transactions and resolve conflicts. And a Merkle tree provides monotonicity. Certificate Transparency works this way.
I agree that the PGP keyserver infrastructure doesn't currently provide this; I'm just asserting that it doesn't take a blockchain to provide it, and there are significant downsides (like waiting for a transaction to commit) to taking that approach.
One thing that a blockchain would provide is the ability to revoke one key in favor of another, and uniquely determine which key supersedes the old. But it's not clear how important that ability is and whether it justifies the tradeoffs of a blockchain approach.
So I'm changing my argument: I think key succession is very important and blockchains do it better. When you revoke a PGP key, you have to rebuild your web of trust from scratch, right? The key is your identity, and continuity is hard. With blockchains, a program is your identity. I can trust your new key immediately if the backup process your program encodes has been fulfilled.
PGP keys can't be used to build identities that are as permanent and resilient as state-issued identities. Blockchains can.
I've had a discussion about this, admitted that credentials and identities are different matters, but were unable to remember or think of any sane solution to this problem. :(
If you know of any — please share!
Decentralization doesn't mean no one's in charge. It means you get to choose who's in charge, and there's zero barrier to replacing someone you put in charge.
This seems sort of like saying, "If you switch to OpenID, you can run your own provider on your own website." Wonderful, but in practice people use some third-party OpenID provider. (A couple people might run a static website with the appropriate link-rel tags, so they keep control of the name but they're still delegating the actual auth work to a third party.)
Is the standard program going to be to grant access to a key + 3-of-5 friends? How do you enroll if you don't yet have 5 friends on the system?
As the ecosystem iterates on identity programs, we'll converge on secure, reliable, decentralized backups.