[noxer]

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.

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.

[mondoveneziano]

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?

[noxer]

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.

[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.