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.
This stuff already exists. See [1] https://xrpl.org/multi-signing.html
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.
> 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?
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.
[1] https://github.com/ripple/rippled/releases
>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.
Problem here is the hard work needs to be done at the beginning. E.g. picture your grandparent needing help using the below.
As a power user, I like it.
Social recovery wallets: https://vitalik.ca/general/2021/01/11/recovery.html
Fortunately there’s little chance of blockchain as in cryptocurrency succeeding outside the scammers and their marks.
That's not much different than git frankly for any given open source project.
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.
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.
Anyway.
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?
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).
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.
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).
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.
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.
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?
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?