This is an extremely solved problem. Unless you have a dramatically interesting solution to the real hard problem, global account recovery, ordinary home users are effectively tethered to their email accounts, because that's how you reset a login. Since you're doing that already, "Sign in with Google" and "Sign in with Apple" are perfectly cromulent solutions and likely to continue dominating.
The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
Meanwhile, the real market for Internet SSO is at companies, and one of the major reasons companies deploy SSO is to have policy control (particularly: onboard and offboarding) of who has access to what. A globally distributed authentication fabric is actually an anti-feature for those people.
The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
Part of what's happening with ideas like this, and the reason Internet identity has been such a tar pit for the last 20 years, is that there isn't one single service model for identity. Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose.
> The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
This is generally a concern I have about blockchain technology. What if it succeeds in its goal to play a major role in some sector, and something immensely important becomes attached to it.
Mistakes happen. Both by humans and by computers. Software having bugs, hardware failing, bits randomly changing in RAM, are all obvious and commonplace. Mitigations exist (ECC, signatures...), but never along the whole chain. For example, BTC addresses might have checksums, but if the wrong row in a database deciding the address is selected in the first place, through human, software, or hardware error, that will not matter.
Do we want to attach extremely important things to a system that is by design irreversible?
Systems build for enterprise usage, for example for banks, do have multi-sign accounts [1]. Each key can have a weight and you define a total that's needed to sign a transaction.
For example 8 keys where each has the weight of 1 and a signing threshold of 4 is required. That would mean form the 8 keys (persons) a maximum of 4 can lose their key.
On top of that you may still have a master key that overrides all.
Or you could lock 4 of the 8 keys in different places not meant to be used but just as backup for the 4 keys in use.
There are almost endless possible solutions that could be implemented if needed.
For example you could make a master key that overrides all others but requires an unlock Tx followed by an arbitrary escrow delay where funds are locked.
This would be useful if a master key is stolen. As soon as someone uses it, it would be known that the key was stolen so the people with the multi-sign key could move the funds away before the funds are unlocked.
You could also make funds move to a previously defined rescue address after a while of inactivity. So in case the key got lost the fund would move to another address you just have to wait. And if the keys are not lost the time is reset every time a Tx is signed. Kinda like a dead man's switch. So people can inherit your funds if you are unable to sign a Tx.
The possibilities are kinda endless. If there is a need for it it can be coded.
Understanding cryptography and smart contracts, what if the increasingly complicated smart contracts you describe have bugs?
> For example you could make a master key that overrides all others but requires an unlock Tx followed by an arbitrary escrow delay where funds are locked.
At what point is switching to a more classical database both worth the increase in efficiency by several orders of magnitude, and the decreased reliance on bug-free code?
These are not smart contracts. Its a functionality of the software that each nodes run. It can be updated if it has bugs. As longs as there is consensus that something actually is a bug. So to use the example above, you would not be able to change the signing threshold of 4 to 3 because that's what you set it to be. Its not a bug if you messed up and lost too many keys. But if the software itself actually handles some edge case wrong then the part of the code can be found fixed and added to the running ledger via amendment.
But since its not a smart contract in the first place, the burden for code to be added is high. While everyone can code something, it has to go trough the amendment process and reach 80% support for 2 weeks before it actually would be applied. There is basically zero chance that something would get 80% support if the active developer team would question the code quality. Every code goes trough audits and runs on the test net first before people even consider to make the amendment.
Still bugs happen and if you look at the change logs [1] you can see bug fixes are common for each new release. Most of these bug fixes dont affect the ledger logic but are just bugs in the node software. So funds can not be lost but in a worst case scenario it could temporary halt the network if such a bug crashes multiple nodes at the same time.
>At what point is switching to a more classical database both worth the increase in efficiency by several orders of magnitude,....
Thats a strange question. That point "is reached" whenever you dont need a blockchain/distributed ledger but instead have situation where the whole system is run by one entity or by a few who have legal agreements with each other. Its like asking at what point you simply write data to a file instead of to a database. There are tons of config files out there and no one suggests that we instead use a database. So why would someone ever switch back from the database to a simple file? Its p much a made up situation that never happens. There must have been a reason to use a database and that reason would need to go away.
Same for DLT. If you dont need it there is mostly no point in using it. There are a few exceptions for example you could use the XRPL to store tiny bits of data for communication between otherwise autonomous systems. The benefit here isn't blockchain/DLT tech but rather that fact that you dont need to maintain servers and the fact that the XRPL has probably the highest uptime of any public internet "storage" you could use. If that is critical then it may be a valid reason. You get the 5 9s (99.999%) uptime that you simply can not buy for cheap anywhere.
But again if you dont need any of the specific properties of a DL there is no point using it and comparing it to other tech with other properties.
The main practical example is git. It does have some partial mitigations for fixing its historical record, for example the mailmap file for correcting names and email addresses. And, I suppose in the worst case a project could rebase its entire history to expunge illegal commits.
Fortunately there’s little chance of blockchain as in cryptocurrency succeeding outside the scammers and their marks.
git does not have a distributed consensus algorithm, however, and does not rely on proof-of-work/space/stake. Whether a rewrite of history is accepted is up to every consumer of any repository individually.
What are you talking about? You misspelled “Ethereum” and Bitcoin never forked with it. Its a totally different thing. Unrelated. Chain splits Are nothing like forking code in open source; forking code is this analogous to altcoins. LTC is a code fork of BTC.
Chain splits are more like a consensus failure and could be likened to a religious scism.
It’s generally undesirable and so are forked coins. There are many many fork coins that nobody cares about.
They presumably didn’t mean a fork between bitcoin and Ethereum, but the variety of forks on those chains.
Ok, well, how many times has the main bitcoin chain had a, uh, so there was the fixing some underflow really early on iirc, I think that counts, but I think that was a soft fork? Has the main bitcoin chain ever had a successful hard fork? I don’t know.
by "the main chain had a successful hard fork" I mean a hard fork where the side that won the common usage of the unadorned name "bitcoin" was the hard side of the fork.
Let's ignore space, where currently the highly elevated risk is well known to the few participants. If we could undo car and plane crashes, we would do it. We cannot, and my question is whether we want to force the same property on accidents that we currently can safely undo.
Another example: Let's assume ownership of a house is defined by a blockchain. Through a mistake, ownership of your house has been transferred to someone else, or lost to an address with no existing private key. Alternatively, you were in the process of buying a house when the same happened.
Would you be happy with the outcome of this simple mistake being irreversible?
If not, and if you think litigation should retransfer ownership to you, what is the value of an immutable ledger, if the house went to a malicious party who does not intend to perform the transfer on said ledger, or to an address without private key, making transfer not possible in the first place?
> Another example: Let's assume ownership of a house is defined by a blockchain. Through a mistake, ownership of your house has been transferred to someone else, or lost to an address with no existing private key. Alternatively, you were in the process of buying a house when the same happened.
I've thought about this a lot, and I think the solution is to use something similar to "social recovery wallets" [0], but with a dao (group of people) as the recovery mechanism. Basically, assume that the blockchain has the correct owner, and require very strong proof to overturn. This has the advantage of making 99.9% of transfers very cheap, rather than 100% of transfers expensive as is now.
RealT is a company that sells "tokenized" real estate, and they do something like this. They assume the ownership on the blockchain is correct, but you can contact them, and they can overturn ownership if you prove that it was stolen or transferred erroneously. I'd personally take this one step further and have a group of people in the community that oversee the process (basically a court, but a lot more efficient and transparent).
If the company in your example can be contacted to overturn ownership, essentially degenerating the immutability and irreversibility of the ledger to levels comparable of existing solutions, then what is the actual advantage of this not only inefficient, but inefficient by design method of bookkeeping?
I find it hard to reconcile "99.9% of transfers very cheap" with the property that at least proof-of-work and proof-of-space actively rely on literally counteracting any effort at becoming more efficient.
"Classical" distributed ledgers in databases are not already more efficient by several orders of magnitude, they are made more efficient through advancements of technology, and those efficiency gains are actively sought out by participants, given that they usually directly translate into profit through reduction of overhead.
> If the company in your example can be contacted to overturn ownership, essentially degenerating the immutability and irreversibility of the ledger to levels comparable of existing solutions, then what is the actual advantage of this not only inefficient, but inefficient by design method of bookkeeping?
Currently when you buy a house, you have to go through a decent amount of effort both in time and money to essentially determine "who owns this house, and are there any liens on it". By using tokenized ownership, you can get rid of this part. Yes, it's not ideal that someone can override the ownership, but it's setup in a way that requires extensive effort and documentation to do.
Ideally the party that could overturn ownership wouldn't be a company, but instead would be an elected, large group of people that determined this. And maybe there could be a way to opt out or select an alternate override?
The point is that this system can be a ton more efficient, enable additional abilities (fractional ownership, instant, extremely low fee loans, etc), all things that the existing system does not allow. Yes, allowing ownership overriding isn't ideal, but I don't think allowing a group to override ownership in a transparent way completely negates all benefits of a system like this.
> I find it hard to reconcile "99.9% of transfers very cheap" with the property that at least proof-of-work and proof-of-space actively rely on literally counteracting any effort at becoming more efficient.
Ethereum will be moving to proof of stake in a year or 2 (> $10B are locked up until this occurs, so I am very confident it will happen).
These are all plausible arguments for associating real estate ownership with a database. What are the arguments for this database being maintained by a blockchain?
If you do not trust the authorities of the locality, e.g. the courts, to properly assign ownership and, more importantly, to defend your claim of ownership through further legal action, then how do you trust the blockchain implementation with its share of elected people and override mechanisms to do the same?
> Yes, it's not ideal that someone can override the ownership [...] Yes, allowing ownership overriding isn't ideal, but I don't think allowing a group to override ownership in a transparent way completely negates all benefits [...]
The assertion already is that mutability and reversibility are necessary and desired properties under the assumption that mistakes and mis-assessments happen, whether through human error or technological failure. The question is, what benefit does a blockchain bring over a regular database under this requirement?
> Ethereum will be moving to proof of stake in a year or 2 (> $10B are locked up until this occurs, so I am very confident it will happen).
I know proof-of-work down to the very detail, I have not yet looked at proof-of-stake. If proof-of-stake exists, and does not share the same problem of massive inefficiency (directly or indirectly), then I still think that a classical database solves these problems more easily, but I cease to care what solutions stakeholders choose. Proof-of-work, on the other hand, makes me and everyone else an unwilling participant in this scheme through unnecessary, and growing, consumption of energy and resources.
I think we're both in agreement that a blockchain is just a glorified database. That said, there are advantages to a blockchain over a database:
With a database, you can only do what the county auditor (or equivalent) lets you do / what their ui lets you do. With a blockchain, you can build things on top of it, fractionalized ownership, simple transfers, etc. It's basically a permissionless database that anyone can build on top of vs a database shoved in a closet at the county auditors that you can only use via their api and ui.
Good points, and in response I would say that not everything needs to happen directly on chain. Just as an example there can be some company that develops an interface between the blockchain and the user that audits their code, insures themselves in the case of software bugs, and provides users with the ability to eject their assets from the platform. Maybe there are regulations that protect consumers against these problems. Crypto/blockchain UX is not even in the "command line" phase yet, we're still writing punch cards and feeding them into computers in my opinion :)
Excellent points. Many real-world problems that people are seeking to solve with a blockchain are often not good fits for the unique attributes that a blockchain has. Many of these problems are best suited to continued centralized administration, or targeted improvements without changing the entire governance model.
Could you explain this a bit more; how does the logic/argument that the problems an immutable blockchain present in this SSO scenario (namely, that it's basically unfixable as a total system) follow that we would never drive cars etc if we continued in that line of thinking?
Cars/planes/rockets seem to be fixable most of the time, or at least we would prefer them to be. (The last one is probably the least-easily fixable, and that is generally considered to be a negative attribute -- something to be mitigated, not celebrated -- and requires careful and even over-engineering because it's so hard/risky to fix a rocket in space.)
Or, perhaps I am completely misunderstanding your point?
The post i was responding to made the point - "do we want to attach extremely important things to a system that is by design irreversible?
Human life is both extremely important, and the loss of it is irreversible, at least for now :). People generally seem to be willing to take risks for the sake of convenience.
But in the end I believe we should be able to have our cake and eat it too - that is benefit from blockchain tech with safeguards preventing such scenarios
Weird. I knew the word already (though not for long), but as a non-native English speaker (German), it also always evoked pictures of scones, or in my case croissants, for me. Maybe because it sounds like "crumbling"?
By the way, on a Mac you can just force press on any word, it gives a definition. Very useful.
> "Part of what's happening with ideas like this, and the reason Internet identity has been such a tar pit for the last 20 years, is that there isn't one single service model for identity. Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose."
Urbit's approach seems pretty good for this? They use Ethereum to manage ID ownership/transfer, but they generate pseudonymous IDs by default (the user can decide if they want to connect them to their real name). They also have a small, but non-zero cost making them not really economically viable for mass spam - people hold on to them and develop reputation with them. There's a lot to like about that model (I think it solves a lot of these issues while also not having the IDs entirely owned by one company).
> The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
You'd think that, but I can't remember how many people have asked me how to implement mutual authentication using whatever random client certs their partners send to them and who don't realize that putting all those issuers in the SSL handshake bloats the heck out of it.
So they may well end up both accepting every random client cert issued by Entrust, Verisign, etc. and then advertising that fact to the world with every SSL handshake.
> fact that people have multiple identities on purpose.
Most people still use the same password (or password management device, or physical MFA device) for both their work and personal logins. This is evidence that most people have the same identity, as would be intuitive. I’m not sure what the bigger picture is, but password secrets are the single service model for identity.
Well one instance of a password manager is somewhat one identity, but that single identity is only known/accessed by me. Everyone else sees multiple identities.
Hey! Author of the thread here. Thanks for your comments!
> This is an extremely solved problem.
Not with the properties of Sign-In with Ethereum (SIE), which is single, user generated authentication credentials, a self-custody portable username in a naming system that isn't reliant on a trusted-third party, and that people are already getting for other reasons (to use Ethereum, so extra incentive to get set up, not just SSO incentive).
> ordinary home users are effectively tethered to their email accounts, because that's how you reset a login
Yep, and I don't expect that to change very much anytime soon, but there is a small but growing community of people tethered to their Ethereum wallets and ENS names and using those instead. Given the advantages and crypto incentives, I expect it to continue to grow. Note also that service can always require a user to also provide an email address, it just wouldn't be used for authentication.
> The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
Doesn't have to be. Three things on this point:
1) Depends on how your wallet provider works. There are already some wallet providers with social recovery (multisig under the hood), etc.
2) Crypto incentives (unrelated to sign-in) mean that the private key management industry ("wallets") is already highly incentivized to make it very difficult for people to totally lose access to their accounts (because then lost money). That's a key part of my point: private key management has never been good enough for average people, but crypto incentives have spurred on a massive industry to solve this problem. And while it's not totally solved (still needs lots of improvement), it has improved rapidly in the last five years to be much better than ever before, and I expect it to continue to improve.
3) What I've described is just on the user side. If a web2 service adopted this (not aware of any right now, it's pretty much just web3 services that use it), they can always do things like require you provide an email address or other information, and they can still have a process for reassigning your account with them to a different Ethereum account.
> The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
Again, depends on what you want, you can make it so that you have access to all of your company's employees Ethereum accounts.
> Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose.
Yep. I don't expect this to replace everything else immediately, but I do expect overtime for this to become a ubiquitous option, such that a user could use their one Ethereum account everywhere if they wanted to.
Also, re the need for multiple identities: as I point out in the thread, a person can generated as many Ethereum accounts and have as many ENS names as they'd like, using their real name or pseudonym, or whatever they'd like.
Anyway, sorry for long comment, thanks for engaging!
It's interesting how much the problems with blockchain SSO mirror those of blockchain currency. In both cases, the goal is to liberate people from centralized authorities. And in both cases, the advocates seem both to radically miscalculate how much the benefit of that shift accrues to ordinary people versus abusers, and almost completely miss the benefits of central authorities, who have at least some incentive to make recoverability and reversibility accessible to consumers.
I don't doubt that there are things you do to facilitate account recovery on immutable distributed ledgers, but it just seems pretty clear to me that you're working against the design of a blockchain when you do that; the blockchain isn't doing much that centralized systems aren't already doing, and they're doing a lot that gets in the way.
Certainly, I wouldn't want to be the person whose job it was to explain to a SOC2 auditor how my company's Ethereum SSO system works.
I wouldn't stake real money on the value of ETH or BTC; the market can stay irrational longer than I can stay solvent &c &c. But I'd probably make a real bet on blockchain-mediated single signon never achieving significant adoption, for some reasonable definition of "significant".
Additionally, they want decentralized logins. People use logins of work and their phone all the time. No work environment is going to give control out to help their employees for example.
No SAAS wants to be unable to help their users.
They mention that DNS isn't meant to be about auth and then they talk about signing your identity with your wallet private keys. I want that to be totally seperated!
And blockchain isn't meant for sso either.
So many people just won't understand any if this, this is just a dead born baby from the start. The statement "many people use this" is probably insignificant in relative terms. I'd be surprised if there are 50 on Belgium in a population of 10 million.
Hey! Author of the thread here. Thanks for your comments!
> This is an extremely solved problem.
Not with the properties of Sign-In with Ethereum (SIE), which is single, user generated authentication credentials, a self-custody portable username in a naming system that isn't reliant on a trusted-third party, and that people are already getting for other reasons (to use Ethereum, so extra incentive to get set up, not just SSO incentive).
> ordinary home users are effectively tethered to their email accounts, because that's how you reset a login
Yep, and I don't expect that to change very much anytime soon, but there is a small but growing community of people tethered to their Ethereum wallets and ENS names and using those instead. Given the advantages and crypto incentives, I expect it to continue to grow. Note also that service can always re
> The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
Doesn't have to be. Depends on how your wallet provider works. There are already some wallet providers with social recovery, etc.
Note two other key things:
1) Crypto incentives (unrelated to sign-in) mean that the private key management industry ("wallet" industry) is already highly incentivized to make it very difficult for people to lose access to their accounts (because then lost money). That's part of my point: private key management has never been good enough for average people, but crypto incentives have spurred on an massive industry to solve this problem. And while it's not solved (still needs improvement), it has improved rapidly in the last five years to be much better than ever before, and I expect it to continue to improve.
2) What I've described is just on the user side. If a web2 service adopted this, they can always do things like require you provide an email address or other information, and they can still have a process for reassigning your account with them to a different Ethereum account.
> The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
Again, depends on what you want, you can make it so that a third-party has access to all of your company's employees Ethereum accounts.
> Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose.
Yep. I don't expect this to replace everything else immediately, but I do expect overtime for this to become a ubiquitous option, such that a user could use their one Ethereum account everywhere if they wanted to. Also, re the need for multiple identities: as i point out in the thread, a person can generated as many Ethereum accounts and have as many ENS names as they'd like.
The actual last thing in the world home users want is an authentication system where credential loss is literally irrevocable.
Meanwhile, the real market for Internet SSO is at companies, and one of the major reasons companies deploy SSO is to have policy control (particularly: onboard and offboarding) of who has access to what. A globally distributed authentication fabric is actually an anti-feature for those people.
The actual last thing in the world corporate users want is an authentication system their IT department doesn't control absolutely.
Part of what's happening with ideas like this, and the reason Internet identity has been such a tar pit for the last 20 years, is that there isn't one single service model for identity. Internet identity evangelists tend to overlook the fact that people have multiple identities on purpose.