But that's just it: bad choices in the social layer become nearly irrevocable once a self-interested, powerful elite emerges. The bad choices put them on top and they will do anything to stay there.

> But that's just it: bad choices in the social layer become nearly irrevocable once a self-interested, powerful elite emerges. The bad choices put them on top and they will do anything to stay there.

I would argue that this trait is not unique to blockchain systems -- in fact, if you presented this argument without context, I doubt many readers would put blockchain in the top 5 potential referents. See: economic systems, political power struggles, social structures, etc.

Agreed 100%.

Satoshi thought bailouts were the problem, but concentrated power was the problem. The libertarian "cure" of stronger property rights only exacerbates power concentration because concentrated power is in the best position to exploit stronger property rights. Cue exponential growth.

Not at all. If a self-interested minority emerges, the majority can fork away anew (see: Steem & Hive).

lol. You forgot to weight by wealth.

Regular economics uses the same dirty trick when it talks about value creation rather than wealth-weighted value creation. It stuffs all its dirty laundry in that one weight term and then "forgets" to talk about it. Oops!

Weight by wealth? You are failing to understand the basic concept of a hard fork. Social consensus doesn't care what your number on the blockchain says.

Case in point, the Hive hard fork.

One very prominent and widely unliked individual purchased majority ownership of the STEEM token. Weighted by wealth, they could now control the chain, its governance, and most notably unlock tokens (20% of the supply) that were (per social consensus between Steem and its community) not supposed to be unlocked.

So, what did the Steem community do in response? They hard forked the platform, launching Hive. All STEEM holders could migrate their assets to Hive, except the individual in question who attempted to takeover Steem via wealth. The malicious elite was cut off entirely. Today, two years on, Hive is still gaining in activity and has more than twice the market cap of STEEM. Comparatively, Steem has become a ghost town.

It is a choice at the software later. And who is making that choice? It's the initial people who actually write that software.

But what if that system is now affecting many other people, or the entire planet in a significant way? Should they have some voice over that?

Under a traditional governance regime the answer is that that is at least possible to change. It may be difficult, but it does not violate the laws of physics and can happen in less time than the heat death of the universe. But we can now write software that makes it functionally impossible for anyone to make that choice, even potentially the original designers. That is an option that we did not have before. It's in some sense the essence of trustlessness.

In some cases, this might be the right trade-off. For example, beyond the blockchain, this is also a way to think about encrypted communications. It is a very significant new power that we can now wield.

But it must be wielded carefully, and that doesn't seem to be happening.

So yes, blockchain applications don't need to be irrevocable. But the ability to make them so is something that could have a very significant implications—potentially negative.

As a somewhat tongue in cheek example, but with a little bit too much reality to be comfortable, this irrevocability might allow you to "create" a paperclip maximizer DAO (incentivized at the social layer, with humans doing the work).

> But what if that system is now affecting many other people, or the entire planet in a significant way? Should they have some voice over that?

This is an important point you are making. What you must recognize is that they absolutely can have some voice over that.

Just as we can write software (or smart contracts) that allow no one to update and fix such issues. We can write software that allows one person to do it. Or we can lock the ability behind a multisig, requiring a majority of the software's developers to do so. Still not good enough for the use case due to far-reaching trust ramifications? Then we write code that delegates the ability to trigger such an update to the entire userbase of the application.

In the world of contract platforms, you have to keep in mind that contracts and the tools that you can build with them are primitives. They are composable. There is no problem in building a DAO to control the ability to update a contract (or trigger arbitrary functions to remedy critical situations caused by unexpected and undesired state changes). This is already done in practice in various applications--and sometimes with undesirable outcomes! Of course, these are still experimental times and lessons are still being learned.

I've heard the metaphor that "writing your ledgers in pen instead of pencil doesn't make transactions irreversible" - meaning that in the same sense, actions on the blockchain could be coded to be irreversible.

The difference is in the authority of who gets to reverse transactions. For example, Tether can freeze and generally arbitrarily control USDT token. USDT therefore isn't really a cryptocurrency, since now a central authority can seize it. It seems to me that this authority undermines why one might want to use crypto in the first place. I don't think you can have it both ways.

It may undermine why you want to use USDT. I don't see why it would affect your desire to use DAI, for example.

The point is that you can have it any way you like it. There are no hard and fast rules like "irrevocability" as described above.

You can have a contract be not updateable, final, and verify its source code to know there are no malicious functions. Or you can have one that is updateable by its developer. Or one that is updateable by an elected authority. Or updateable by a DAO of the contract's users. There's no single way to do it or perfect solution.

Like most software development, it is the understanding of application requirements and selection of tradeoffs.

The outcomes of malfunctioning "smart contracts" are irrevocable.

Wrong. Smart contracts can be updated. If they are deployed with the ability to update, any outcome can be revoked. It is as simple as adding a new function.

?? Updating a smart contract does not rollback the history of transactions, a wallet drained due to a buggy contract is drained for good, that’s what “irrevocable outcome” refers to.

You're missing the point. You don't need to rollback past transactions that make unwanted changes to the contract state. If you have the ability to update a contract, you can add whatever functionality you need to undo a given state transition. You invoke the new function with a new transaction. The old transactions don't suddenly not happen. Your new transaction simply reverses the state changes, making it as if they hadn't affected the state at all.

It's likely that you aren't considering this possibility because, of course, the average token contract does not do this. It would be a significant trust violation if a contract controller circumnavigated the need for signature checking or allowance setting in order to perform arbitrary token transfers. That does *not* mean the possibility for it to be done does not exist.

At the end of the day, token balances are just key-values in the contract storage, and how those values are changed is enforced at the contract code level. That code can say whatever its controller wants it to say, and if they deploy with the ability to update, they can alter the code as necessary in the future. Token contracts are extremely simply, easy to audit, and so are seldom deployed to be updateable.

To summarize, "irrevocable outcome" is not a fundamental trait of a smart contract application. It is a choice at the code level, with tradeoffs, which can be adapted to suit the application.