What criteria would you suggest to determine whether a task or function is better executed on a permissionless blockchain, as compared to a centralized system?

"What criteria would you suggest to determine whether a task or function is better executed... on a permissionless blockchain, as compared to a centralized system?" "Do you think permissioned blockchains are real blockchains? Do they have a role too?" This is an interesting question, D.J. Permissioned blockchains are blockchains, sure. What they are not is open blockchains or permissionless blockchains. They are blockchains, they just don't have any of the interesting features we find in open blockchains. Some of the features that people ascribe to blockchains, are not features of [all] blockchains. They are features of open, decentralised blockchains. For example, immutability is [about] recording something and having a guarantee... that it cannot be changed [later], even if verifiers are coerced into changing it.

Bitcoin is a system that provides the immutability guarantee

Bitcoin is a system that provides the immutability guarantee. Even if 100% of the miners wanted to change the blockchain, or were being coerced to do so, they still [must] expend the proof-of-work energy, or risk their blocks being invalidated by the rest of the system. There is no shortcut. Proof-of-work, and the decentralised nature of the consensus algorithm, creates immutability. If you have a system of federated signers, a permissioned or private blockchain, "decentralised ledger technology" as it is sometimes called... Let's say you have a group of sixteen signers: sixteen members of a coalition, the largest participants in a stock market or bank transfer network. They are all federated signers. If you serve a subpoena to all sixteen of them and say, "You must change this transaction," or "Make sure [this transaction] never happens," "This transaction back in January was paid to WikiLeaks and we don't like that." "Here is a court order that says the transaction never happened. Please amend your blockchain." The federated signers can do that; if they can do that, then under the law they must do that. It is no longer immutable, no longer censorship resistant, no longer neutral, no longer borderless. These federated signers are subject to the jurisdiction of whichever state they are in. They can't open it up. It is no longer permissionless because they [must] vet every participant. The issue here is, once you take out the decentralized nature of validation in the consensus algorithm, then a lot of the things you think blockchains do -- giving you censorship-resistant, neutral, permissionless, immutable transactions -- go away. What you have is a distributed database for recording transactions, if the federated signers want to allow it; something that is not immutable, censorship-resistant, neutral, borderless, or permissionless anymore. Is that thing useful? It depends on what you are trying to achieve. If the application you're trying to achieve doesn't need censorship resistance, neutrality, borderless access, or immutability, then maybe it is useful. Of course, you [will] have other challenges.

In an environment of federated signing, you have the problem that the signers are usually competitors

In an environment of federated signing, you have the problem that the signers are usually competitors. Therefore they [will] try to tweak the system to give [themselves] maximum advantage. In a decentralized blockchain, the self approach (where everyone is assumed to act purely in their self-interest) is the basis of the game theory that makes it secure. As long as everybody acts in their best interest, the system is actually fair, predictable, and secure. That is how proof-of-work works. It assumes that everyone will act purely in their self-interest, but because they're constrained by the [rules of the] system, they are forced to operate it [honestly]. [Honesty is] in their best interest.

However, in a permissioned system, if the federated participants are acting in their own self-interest, you have a problem because they can be identified and coerced

However, in a permissioned system, if the federated participants are acting in their own self-interest, you have a problem because they can be identified and coerced. They have to participate in a collaborative manner [while being competitors], so the incentives are misaligned. You can see this every time you look at an industry trying to create common standards by committee. They may start off with good intentions. 'Let's make a new standard for how we do financial exchange protocols." As the participants get together, each one has a vision of what will be in their best interest, and try to add that to the standard. The standard gradually [becomes] more complex because of this jockeying for position. In the end, it is not really a standard, but a wishlist collection and kitchen sink 'bikeshedding' that happens. These standards don't get applied in the real world because they're too complex. There is too much opportunity for one party to take advantage of another. A classic thing you see in protocol development is... big companies [coming] together to build a common standard, [while their] lawyers are in the background... filing patents for those same things, in order to gain an unfair advantage. This happens all the time. You see, over decades of attempts to [make common standards in banking, this continue to collapse. Whenever the standard is designed by committee, all this jockeying for position results in a mess.

Theoretically, permissioned blockchains with federated signing based on a common standard would bring the industry together, create more collaboration

Theoretically, permissioned blockchains with federated signing based on a common standard... would bring the industry together, create more collaboration, allow banks to have faster and fairer networks for transactions. In practice, they never get there because of squabbling and jockeying for position internally. They end up creating either a terrible standard that doesn't serve anyone's needs, or a standard that nobody uses because they feel they will be at a disadvantage... because the standard mostly expresses somebody else's interests. We have seen this again and again, most recently with R3 and their efforts to create standardized financial services blockchains. Again, all the prototype implementations have not succeeded. We saw this with internet protocols too. TCP/IP was not the obvious winner. Today, it is clear that the internet is TCP/IP. But back in the early '90s, the conversation was very different. People said TCP/IP [would be]... an interesting -- but edge -- case of the information superhighway, which would be primarily based on... robust enterprise protocols like the ISO, OSI, TP4 for example. Protocols like ATM and those proposed by IBM, Microsoft, and other [companies]. TCP/IP [was] a small corner of the information superhighway, mostly [used by] academics. TCP/IP wasn't really suitable for enterprise because it didn't have enough features that enterprise wanted. Where did we end up? The "information superhighway" is a silly term that people laugh at today. The internet is TCP/IP. You have probably never heard of the other protocols, TP for an ATM and the OSI stack. You probably don't run ISDN. Those were proposed by the telecom companies. All of these things went to the wayside. Why? The value [of the internet] came from open, interoperable protocols where no one had a distinct advantage. We [will] see the same thing happen with blockchains.