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