how long would it take to authenticate against this system?
You mean once it’s built out and implemented? Not long at all, it would be nearly instant, depending on how services and clients decide to use the "priv" key (which is optional).
If they’re storing the encrypted private key "priv" in the blockchain, a possible scenario would go like so:
User loads page with challenge from server containing a nonce or something
User enters their username and password into secured text fields[^1]
Client software retrieves the "blockchainid" information from the blockchain (via say, DNSChain, or a thin client) and decrypts "priv" using the password, gets the private key and signs the challenge.
That’s very fast from a UX perspective.
If they’re not storing "priv" in the blockchain and are instead using some other login mechanism, it depends entirely on that other mechanism. For example, they could be using something like SQRL or similar to store the private key on their phone. Or their private key could be in a Trezor-type device (who knows?).
The system is very flexible and allows for various different mechanisms. The point is that it’s completely decentralized and doesn’t rely on providers the way OpenID and Facebook Login et. al. do.
[^1] “secured text fields” refers to any secure input mechanism, could be a browser extension for example, or some secure hardware. You wouldn’t want users entering their password directly into an HTML form sent by the server.
I think this is all a great idea. The only problem I see is the economics of sharing compute work. In bitcoin, all these blockchain calculations are performed in exchange for new bitcoins. What incentive do members have to continue number crunching in this system?
The only problem I see is the economics of sharing compute work. In bitcoin, all these blockchain calculations are performed in exchange for new bitcoins. What incentive do members have to continue number crunching in this system?
I’m not sure I understand your question. Those are completely orthogonal issues (as far as I can tell). This is not a new blockchain. It’s simply a specification for data that’s stored in a blockchain (any blockchain that can do key/value mappings, some examples are given in the README).
I apologize if this is a dumb question, but how long would it take to authenticate against this system?
You mean once it’s built out and implemented? Not long at all, it would be nearly instant, depending on how services and clients decide to use the
"priv"key (which is optional).If they’re storing the encrypted private key
"priv"in the blockchain, a possible scenario would go like so:"blockchainid"information from the blockchain (via say, DNSChain, or a thin client) and decrypts"priv"using the password, gets the private key and signs the challenge.That’s very fast from a UX perspective.
If they’re not storing
"priv"in the blockchain and are instead using some other login mechanism, it depends entirely on that other mechanism. For example, they could be using something like SQRL or similar to store the private key on their phone. Or their private key could be in a Trezor-type device (who knows?).The system is very flexible and allows for various different mechanisms. The point is that it’s completely decentralized and doesn’t rely on providers the way OpenID and Facebook Login et. al. do.
[^1] “secured text fields” refers to any secure input mechanism, could be a browser extension for example, or some secure hardware. You wouldn’t want users entering their password directly into an HTML form sent by the server.
I think this is all a great idea. The only problem I see is the economics of sharing compute work. In bitcoin, all these blockchain calculations are performed in exchange for new bitcoins. What incentive do members have to continue number crunching in this system?
I’m not sure I understand your question. Those are completely orthogonal issues (as far as I can tell). This is not a new blockchain. It’s simply a specification for data that’s stored in a blockchain (any blockchain that can do key/value mappings, some examples are given in the README).