Hacker News new | past | comments | ask | show | jobs | submit login
The Private Blockchain Fallacy (berk.es)
110 points by berkes 11 months ago | hide | past | web | favorite | 107 comments



I've worked on private blockchain solutions for financial firms (in supply chain and commodity trade finance). The reason companies are doing these projects is because in a lot of scenarios no one trusts each other. Even if they do, there are not allowed to for legal and compliance reasons. As such huge parts of the industry are paper based. Because if there was a simple MySQL solution from a company they would have gone with that 2 decades ago.

The article talks about reasons for wanting a private blockchain. But I have never heard any of these reasons come up in any of my projects. I'm not sure what projects the author is talking about, but definitely not anything related to what most private blockchain projects companies are doing. That said there is a lot of hype in the space (not denying that).

You can make an argument that bitcoin in the whitepaper was defined as an open access system, and as such any closed access system is not a blockchain. Sure, but the developers on these projects (like me) are calling them blockchains nonetheless because most the of the tech is the same (except for things like consensus forming, you probably would never use PoW in a private blockchain).

----

Companies are looking into private blockchains because they allow for systems where not one party is in charge of all the data and the network. But they require more than an append only log.


There are a lot of issues with your thinking. I will just start with a few ones.

One is that in a trustless blockchain like Bitcoin your source of truth is the blockchain, no external force (based on some security assumptions) can change that. In a private blockchain the source of truth is the law, if the organizations signed their transactions, published it in a typical SQL database but they were not recognized by the other parties you can sue other parties legally. This is not possible with public blockchains.

Another is the number of security point of failures you have. If you use your blockchain for supply chain but the input to the supply chain depends on devices, since all these devices can be hacked or impersonated you cannot trust them.

> Because if there was a simple MySQL solution from a company they would have gone with that 2 decades ago.

No, this is an organizational problem where different organizations cannot agree on different protocols. It is difficult to agree on a common API, workflow, etc if you have 100 organizations.


> Another is the number of security point of failures you have. If you use your blockchain for supply chain but the input to the supply chain depends on devices, since all these devices can be hacked or impersonated you cannot trust them.

I don't know any private blockchains that have apps running on smartphones that connect directly to them. Companies have IT systems (what your app talks to) running in private clouds protected by cameras, people with guns and layers of firewalls. And those systems interface with a private blockchain. Authenticating over a number of factors (eg. 2FA) is obviously done, but that's unrelated from the blockchain.

> In a private blockchain the source of truth is the law

Definitely not true (in any jurisdiction I have worked in, mostly EU), and if it was lawsuits are very expensive and drag out over long periods of time.

> No, this is an organizational problem where different organizations cannot agree on different protocols. It is difficult to agree on a common API, workflow, etc if you have 100 organizations.

You're right that it's hard, but that's definitely not the problem in any of the projects I have worked in. The problem is trust.


> I don't know any private blockchains that have apps running on smartphones

In the example you mentioned: supply chain, you have an external device (outside the blockchain) pushing transactions to the blockchain. You can see this example repeated over a billion of times, it is the typical private blockchain use case. I am not inventing anything new here, just exposing the claim vs. the reality.

> Definitely not true (in any jurisdiction I have worked in, mostly EU), and if it was lawsuits are very expensive and drag out over long periods of time.

The law is the last resource I cannot imagine NASDAQ and financial institutions having security issues because the financial institution doesn't recognize a message signed by NASDAQ. This is clearly ridiculous. This can be handled in many ways If the message was signed because of fraud or a security breach.


> I am not inventing anything new here, just exposing the claim vs. the reality.

I have worked on on proof of concept experiments that did this. Because it's easier to showcase "data goes in here, comes out there". But that's obviously not how these products will run in production. All these experiments aim to test/showcase the viability of using a blockchain between parties. The app is just there to show the business people how it works (also for PR reasons).

> The law is the last resources I cannot imagine NASDAQ and financial institutions having security issues because the financial institution doesn't recognize a message signed by NASDAQ. This is clearly ridiculous.

I'm not saying that if NASDAQ signs a message that won't hold up as proof that NASDAQ said something. I am saying that if two parties engage in a transaction and it's recorded in a digital contract on a blockchain, that might not always be enforceable as such in a court.


As you said you worked on proof of concepts, not production ready products. Show me a production ready product and I can show you how you can do the same without a blockchain.

As I said before and can expand now, blockchains have very specific security assumptions that are not present in a public blockchain. Once you remove those assumptions cryptographic protocols are enough to give security when organizations are not anonymous.

> I am saying that if two parties engage in a transaction and it's recorded in a digital contract on a blockchain, that might not always be enforceable as such in a court.

Digital signatures are recognized by the law in most countries.


> Digital signatures are recognized by the law in most countries.

Digital contracts are not. If you believe they are, start posting some examples like you keep asking me to do.

> Show me a production ready product and I can show you how you can do the same without a blockchain.

I don't know any production blockchain solutions I'm allowed to talk about. Do you know any?


Digital contracts are recognized if you have a private contracts agreeing on recognizing them.

> I don't know any production blockchain solutions

Nothing more to say. There is no production ready private blockchain to show.

BTW, I work in this field in very well known projects (e.g. RSK, Algorand, Xapo, Jaxx, Ripio) in the public blockchain space and have adviced companies like MuleSoft at the CXX level in the private blockchain space.


[flagged]


> Pulling things out of context eh ;) It's unfortunate you're not aware of any production ready private blockchain solutions. Maybe keep that in mind before you start with your next discussion.

Correction: I am not aware of any production ready private blockchain that cannot be replaced by another technology not using blockchain.

> Woah your e-penis is indeed very long! I am impressed!

It seems you don't know how to talk here in HN. You started your thread saying "I've worked on private blockchain solutions for financial firms" then there are many of your comments where you are showing some level of experience. I am showing my level of experience in the business like you.


> You started your thread saying "I've worked on private blockchain solutions for financial firms"

Yes: I stated "I work in this field, this is what I see around me at companies that are doing private blockchains. I haven't heard these arguments around me before."

While your approach is: "Here is my resume, now I demand you to give me examples so I can prove my point."

> Correction: I am not aware of any production ready private blockchain that cannot be replaced by another technology not using blockchain.

Ah great! Since your argument is that they can all be replaced, can you name a private blockchain solution that IS running in production that can be replaced?

While you are at it:

> Digital contracts are recognized if you have a private contracts agreeing on recognizing them.

IANAL but AFAIK this is completely false. Do you have any examples of smart contracts running on blockchains being enforced in a court?


> While your approach is: "Here is my resume, now I demand you to give me examples so I can prove my point."

I already probed my point beyond what I said afterwards. You just need existing cryptography and don't need a blockchain to make secure agreements between parties.

> Ah great! Since your argument is that they can all be replaced, can you name a private blockchain solution that IS running in production that can be replaced?

I don't need to since I am arguing about the no sense of private blockchains.

> IANAL but AFAIK this is completely false. Do you have any examples of smart contracts running on blockchains being enforced in a court?

If the smart contract uses digital signatures they are enforced by the existing law.

Also, as you probably know, this field is very new and the law was not, in general, involved with this kind of technologies.


They might not trust each others but if they know each others, why can’t they simply use a public private key solution? For a transaction to be valid it needs to have been signed by both parties.


They can and do. What's most useful about blockchain tech is the eventually immutable chronological ordering bit.

As an example, 2 parties can enter into a contract. The contract details are signed by both parties. The contract is placed on a blockchain that's visible to both parties and any interested regulators etc. You can even use the same chain for multiple competing parties simply by encrypting the contracts.

Note, this isn't acting as a transaction in the Bitcoin sense. It's simply using the basic mechanism of linked, hashed blocks to establish a permanent time-ordered ledger.

Time passes. Now, if there's any dispute, all parties have a shared view of exactly what occurred when. It's not practical to manipulate it as the parties know who they all are and can easily resort to external measures.

But it does solve a huge, very expensive problem that financial institutions and regulators have: a single, shared version of the truth. This is a multi-million dollar problem and blockchain tech can definitely be part of the solution.


> They can and do. What's most useful about blockchain tech is the eventually immutable chronological ordering bit.

> As an example, 2 parties can enter into a contract. The contract details are signed by both parties. The contract is placed on a blockchain that's visible to both parties and any interested regulators etc. You can even use the same chain for multiple competing parties simply by encrypting the contracts.

> Note, this isn't acting as a transaction in the Bitcoin sense. It's simply using the basic mechanism of linked, hashed blocks to establish a permanent time-ordered ledger.

For this, you do not need a blockchain. Instead hashed and signed non-cyclic data structures suffice (e.g. hash lists [1], hash chains [2], hash trees). Note that the Merkle trees ([3]) that are used in Bitcoin are special cases of hash trees.

According to [3], "[t]he concept of hash trees is named after Ralph Merkle who patented it in 1979.".

What do blockchains solve that cannot be solved by these data structures that are 40 years old? The answer is: decentral consensus when the parties cannot trust each other. This was the missing building block that was necessary to build a decentral cryptocurrency.

[1] https://en.wikipedia.org/w/index.php?title=Hash_list&oldid=8...

[2] https://en.wikipedia.org/wiki/Hash_chain

[3] https://en.wikipedia.org/w/index.php?title=Merkle_tree&oldid...


> This was the missing building block that was necessary to build a decentral cryptocurrency.

Indeed. But if that's not what you want then you can drop that bit and use the rest.

If your point is that nothing stopped people doing this a generation ago, if they'd thought about it, then I agree completely.

But the key bit is they didn't think about it (or think it was sufficiently important). What Bitcoin did was publicize the techniques and, crucially, show that the interesting bits work well.

Of course, if you choose to use a definition of blockchain that involves trustlessness then the usage I described isn't blockchain, by definition. By I tend to use Satoshi's definition, more or less, which is orthogonal to the idea of trust.


> If your point is that nothing stopped people doing this a generation ago, if they'd thought about it, then I agree completely.

> But the key bit is they didn't think about it (or think it was sufficiently important).

My opinion on this topic rather is: everything (except how to build decentralized trust) has been known for a long time. It is also known for a very long time that these techniques work well (otherwise Satoshi Nakamoto would never have come up with the idea to make them a central piece of Bitcoin). The central reason why it wasn't implemented before rather was that the people who knew about it did not have the charisma to convince "the people with money" that they should finance an implementation.

For example, already in 1989, there was an attempt to build a digital anonymous (though not decentral as far as I know) currency called DigiCash by David Chaum:

> https://en.wikipedia.org/w/index.php?title=DigiCash&oldid=83...

What happened to them? This company simply went bankrupt in 1998.


DigiCash lacked the novel, decentralized proof of work consensus introduced by Bitcoin and I also suspect the general public was much better able to participate with 2008 broadband than what we had 1998


Very true, in my experience talking with lawyers is that blockchains are still very far away from having any type of legal meaning: if there is a problem down the line you can't refer to the blockchain in a lawsuit (IANAL).


This seems a little hard to believe given that in today's lawsuits the parties are often referring to emails. What's the fundamental difference between an email and a txn in a block?


In my understanding you can definitely point to some tx and say that has something to do with the other party. But if there is a "contract" between two companies, like company A should give this in these circumstances to company B. If there is then a dispute about these circumstances, it matters whether the contract was on paper with actual signatures (a document designed to be able to be enforced by law) or a "smart contract" on a blockchain system somewhere. In case of the latter you cannot say "I want my money because the contract says so" if the contract only exists as a smart contract on a blockchain. If it's on paper the decision might be based on the actual wording (in English or another language) - this is all very hard when you're dealing with a programming language (or set of instructions).

But as I said, IANAL.


Could this be solved with a git repository and signed commits?


If you read the definition of blockchain by Nakamoto in the post, the most important point of a blockchain is to provably keep track of the order of the transactions. That is not so easy to achieve with just a public key infrastructure. Actually, timestamping is a very difficult problem and bitcoin solved it.


Timestamping only works in bitcoin due to The consensus protocol, which prevents involved parties from forging transaction timestamps


For compliance and privacy reasons. For example I deal with a lot of Swiss banks and Swiss law is very strict about what kind of data is allowed to leave Switzerland (not very much).


Is it privacy as in no one must be aware that this particular party signed a contract?

Otherwise the public/private key could also be used for the encryption of the contract. Then you have an encrypted blob signed by both parties, and any of these two parties can decrypt it.

What I am not sure I get is why you need a block chain when the parties know each others. If they exchange public keys (and financial institutions have to go through a lengthy KYC process anyway), do you need a proof of work mechanism given that a transaction could be validated simply by both parties signing it.


I'm not sure that @askmike uses PoW in his project(s). It sounds like if the companies know each other and can form consensus, they don't need PoW to form consensus.


They indeed don't need that. Nor PoS.

What is more, when there is a "consortium of companies that do no trust eachother using a private blockchain" they imply three things:

* They have a permissioned system: not everyone can participate. This means there is a mechanism to punish adversaries right there: just remove their permissions! A large part of what "a blockchain" is all about, is dealing with sybil attacks stemming from the requirement of it being permissionless. * They know eachother. Hence there won't be a sybil attack possible. * They have established communication channels (otherwise it is impossible to grant access to the private blockchain). Hence the Byzantine problem is non-existing or not an actual problem.

Maybe, very maybe, there is a case for a private blockchain in which there are many participants and a system to fully anonymize all these participants once they "are inside the firewall". I really cannot comprehend this, though. But that would make a case for a private blockchain, becayse sybil attacks are then again possible and need to be dealt with.


You probably need chronological ordering as well, and to broadcast transactions to all stakeholders, and tools to interact with and verify the structure, and to not roll your own crypto - all of which are provided by following the "blockchain" standard.


> Otherwise the public/private key could also be used for the encryption of the contract.

No bank inside the EU is allowed to send one bitcoin to another bank for the reason that the miner (a service provider) is not KYCed. There are ways around this (by not broadcasting the UTXO in the open, but only giving it to a miner you KYCed before - but other things like in some jurisdictions bitcoin isn't fungible from a legal perspective, meaning the Bank is required to have KYCed everyone who ever owned that Bitcoin). In other words, public blockchains are a world of pain from a compliance perspective in highly regulated fields (like banking).

Note that technology is a few steps ahead of legislators. And banks cannot take any risk in doing things they are not allowed to do.

> Otherwise the public/private key could also be used for the encryption of the contract. Then you have an encrypted blob signed by both parties, and any of these two parties can decrypt it.

If no one is able to validate the contract, why push it through the blockchain at all? Just use PGP over e-mail? That said: it's an interesting approach and a number of blockchain systems offer you to do exactly this: you have a contract with another party (node on the network), you both sign and it push the hash to the blockchain. So that everyone in the network can form consensus over that you and someone agreed to some contract that hashed to Y (for example private transactions in Quorum). But note that here you are still leaking a lot of data: people can figure out you have a contract with someone else, etc.

> What I am not sure I get is why you need a block chain when the parties know each others. If they exchange public keys (and financial institutions have to go through a lengthy KYC process anyway), do you need a proof of work mechanism given that a transaction could be validated simply by both parties signing it.

The KYC is indeed lengthy, but only a small part of the story:

I'm dealing with a lot of situations that are like "a chain of contracts". In commodity trade finance you'll have contracts between buyers and sellers, and both of them can use a bank. There are a huge number of parties involved and between all of them there are contracts (the seller is going to ship some goods, for example by boat between different countries - this requires a ton of parties and certificates, documents from customs, etc).

All of these contracts kind of rely on each other, for example the contract between the banks (the LC) has a lot of information regarding what was sold and bought - and this needs to match whats in all the other contracts and documents. Right now you have huge departments where people are going over this manually (multiple times per party), there is some software but there is not very much digitally communicated between companies.

Note that most of these contracts are signed months before the sale, and in most cases most people in this chain are not allowed to see the whole chain, just a small part that concerns them. At specific times (not when the contract is signed).

A private blockchain allows you to build these kind of solutions. With a public blockchain you can too but there are many more obstacles. What if the encryption is broken 20 years down the line? All the data would be on the street..


but would a blockchain solve this? Wouldnt the data leave switzerland this way as well?


Definitely not. You can build a small network (eg. pegged sidechain) within different Swiss datacenters owned by different companies.

It's not trivial, but at least possible. Because if you are bank you cannot ignore the law because you want to use Ethereum mainnet.


privacy.


If you don't mind asking, what kind of actual use cases do you see in the supply chain environment for blockchain? I would assume the financa part would be more suitable, but up to now I didn't find a use case where I personally see the benefit. As I assume I might miss something it would be great to hear your opinion on it.


As an example, food safety in the developing world. Food firms claim food is fresh and came from places where it did not come from. If you introduce an agricultural and food tagging system that logs food item IDs into a blockchain-based system, you can know when and where food was made and grown.

Note that this ignores the huge expense of measuring and storing all of this data, but I've seen some interest in these use cases in Asia, especially for staple crops like rice.


How does that in anyway protect against fraud?


You don't take the data at face value. The goal of these systems is to reduce human intervention, not to remove the intervention. If a firm fakes data, you still have proof in the bad products and customer complaints. This lets you investigate and file complaints on the public blockchain. Think of it like a review of a company's supply chain reliability.

More advanced systems consider using third party, tamper proof scanning systems and packaging. Again, the costs of these systems are quite high, especially for food, but there are physical ways to reduce fraud if the data holds enough value.


> If a firm fakes data, you still have proof in the bad products and customer complaints.

Someone who fakes products can read the blockchain and print fake labels based on what is there.

> This lets you investigate and file complaints on the public blockchain. Think of it like a review of a company's supply chain reliability.

So the blockchain in this case is used as company review database? How is a blockchain useful for that?


They can always print fake labels, but they can't deliver fake products too many times. Customers will realize that fraud is happening. Again, there are also ways to make labels that cannot be faked, then attach those labels to tamper-proof packaging. It helps to realize that these labels and packaging exist so that the food items can be scanned and tracked as they enter and leave different facilities along the supply chain.

A blockchain is useful as a review database because you have guarantees that the reviews came from the claimed reviewer. This reduces fake claim fraud, which you might, for example, see in restaurant reviews. The reputation of the purchasing company is also at stake when they make claims that another company committed fraud. You want good guarantees that information came from the party it's ascribed to. It's reputation building in a scenario without mutual trust.


Hard to say for me, because the obstacles and problems in these projects are always legal and business. I'm just an engineer ;)

> use case where I personally see the benefit

This is just infrastructure (as it should be), right now the middlemen are very expensive because of all the paper documents going between companies, and all the people hired to go over all of them. The usual arguments for these projects are:

- Cheaper

- Quicker decision making & communication

- Less fraud & errors

For us consumers that would probably result in cheaper apples in the the grocery store I guess.


Thanks for the quick answer! So it would be fair to say to get rid of the paper work by making it digital and using blockchain to reduce the fraud risk?

Anyway, I'm really curious to see what people come up with! And yes, being faster and cheaper is summing up logisitcs pretty well! ;-)


> So it would be fair to say to get rid of the paper work by making it digital and using blockchain to reduce the fraud risk?

I'm no expert on fraud, but I think most of it comes when data enters a system. With a blockchain (or any digital system really) you can easily check that your data stays consistent (when it needs to be between different documents and contracts). But if the guy entering how many tons of apple are in this container is lying about it a blockchain won't really help you.


Can you point at any examples / elaborations on the subtleties here - almost a "how / why to write your own private blockchain"?

I am interested in esp not using PoW in consensus - what makes consensus??


I'm only involved with proof of concepts, as such I usually work with pre made blockchain solutions with smart contracts slapped on top.

Consensus is arguably the hardest part of a blockchain (if you need distributed data storage just use something like IPFS). An example is Quorum (JP morgan fork of Ethereum), this is their take on consensus algorithms:

https://github.com/jpmorganchase/quorum/wiki/Quorum-Consensu...


Thank you


If the author is reading this, the most interesting thing about your article is that it creeps towards the recognition of something important (i.e. that data ordering and data permanence are quite different things) before it balks at the implications and adds unnecessary properties to its definition of a blockchain.

This makes the piece come across ideological. As a case in point, you write that the public aspect of a blockchain is what ensures its permanence but that is not at all the case. The public aspect is what guarantees open access. Open access in turn guarantee decentralization under conditions where decentralization is economically feasible. The only thing that guarantees permanence is the economic incentive structure that pays participants to store and distribute data.

We don't have a good taxonomy for discussing these ideas yet, but most people working on scale are beyond this. Ethereum is experimenting with rent. Bitcoin variants exist which have adjusted their genesis block manually. Some layer-two networks are designed be transient, while Saito uses a transient blockchain to put bandwidth-intensive applications directly the first layer. The direction of development in the space is tilting very clearly towards utility networks and disposable data-structures. The disagreement is over at what layer this needs to take place, and how to preserve things like open access while paying for things like bandwidth and storage.


Thanks for your summary. Indeed it is very hard to explain these ideas, because so many terms are still vague, missing or explained in often contraditing ways.

I think, indeed, that with "permanence" i've made the mistake to pull that together with "immutability". My first draft had them as different points, but I found that this made the explanation too complex. So I decided to go only for "immutability" and to move the "permanence" under there.

In your definition of permanence (the correct one, BTW) this is not the same. Permanence needs economic incentives. As we can see with IPFS (and it not -yet- being permanent in practice). Immutability, however, needs (i) cryptography and (ii) conflict resolution and (iii) permanence. Which implies "being public". As I tried to explain.

Or did I misunderstand your comment, and do you mean immutability as well as permanence?


I really just wanted to comment because almost no-one gets what you wrote about the importance of data-ordering. So the piece started strong, but then felt like it started tripping over itself.

On the permanence/immutability issue, I guess my opinion is that permanence is distinct from immutability and that while all blockchains require immutability, they can exist with varying degrees of data persistence. I tend to think bitcoin would be perfectly safe running on a 100 year chain with periodic hardforks to upgrade the genesis hash, for instance, and that it would be a bit strange to suggest that this wouldn't count as a blockchain, even if the trade-offs would make the network lose some properties of "digital gold". At a minimum, arguing otherwise would seem to imply that UBTC isn't a blockchain, which is obviously wrong.


I’ve worked for a company obsessed with blockchains. What really happens in my experience is that some clueless business person tells the boffins to work on it, because they’re super scared of the hype that this new tech might destroy them. But they don’t understand it all.

Exercise for the blockchain advocates: explain as simply as possible why a “private blockchain” is better than Git.


> Exercise for the blockchain advocates: explain as simply as possible why a “private blockchain” is better than Git.

Because with git you either go:

- The linux way with one upstream and everyone branching of the "main" repo: In a lot of ways everyone is relying on the centralized main repo of linux, and in every other way they disagree on the final state (eg. the final code).

- The "github" way where there is one version hosted on a centralized service that everyone needs to trust.

Beyond the obvious security problems when trying to use git for actually important data ( for example: https://shattered.io/ ), git doesn't help you in any way to come to a consensus about what happened and in what order. Instead it gives tools to rewrite history as how you see fit (like rebase).


Basically in both cases the problem is a centralized repo, right? That's not really a problem with signed commits though, is it? E.g. Google's certificate transparency or Keybase. At this point we are arguing over the definition of Git vs private blockchain though. I just don't get the hype. Merkle trees have been around since the 70s.


Well in the first case the problem is the lack of centralized repo: there are a million and one forks of linux, and they are all linux however they have all different code (Linus maintains the one that most people call linux, but there all Linux nonetheless). Imagine if it wasn't code, but financial data that would not really work.. The problem with git is that it doesn't allow you to form any consensus with a group of people (that you can't always trust). git's answer to 2 people committing to the same file is to throw a merge conflict in your face: Git is saying: I can't figure out what the truth anymore, so please tell me. That only works if you can trust everyone.

> Merkle trees have been around since the 70s.

Blockchains didn't reinvent many things, 95% of a blockchain is basic cryptography. Merkle trees are awesome and they are used as well (for example when grouping transactions into blocks within Bitcoin). The reason why you need more than a merkle tree is because a merkle tree doesn't help you if:

- You can't trust one single party to maintain (or host) the whole thing: yes you can use digital signatures to make sure they don't forge what you said. But what if they deny you access and ignore your messages? What if they change the order people said things? A merkle tree can't protect you from this.

- You need to agree with other people in what order certain things happened, this is a hard problem in networks / distributed systems. Especially if you have actors trying to manipulate this very thing.

- You need to align incentives in a way that breaking the complete system is infeasible from a financial point of view.

----

Take Bitcoin as an example, a (kind of) anonymous payment system in the internet, the only things protecting everyone's money are public/private cryptography and the costs involved with rewriting history (51% attack). Bad actors attack it every day, but no matter who's door the police kicks in you only have to trust cryptography (the only other weak link is your personal private key, so if you they hit in your door - but there is no other middlemen).

> I just don't get the hype.

There is a ton of hype, and whether it's valid or not depends on if the world needs such a system. Blockchain proponents say that once you have a stable decentralized system that can run any code and cannot be corrupted in any way, you will see innovation flourishing similar to the internet: the internet brought complete freedom of information (and industries build on top were not imaginable in the 80s), some people think the blockchain will bring freedom to anything that is (or should be) scarce. Like money and commodities.


To be clear, what are you trying to convince me of? The target keeps moving. Are you trying to convince me that a blockchain is needed instead of Git for a currency like Bitcoin? In that case I agree. In fact I conjecture that blockchains are only useful for cryptocurrency. Or, are you trying to convince me that a blockchain is useful for businesses for something like “the supply chain” or whatever, without any cryptocurrency? If so, then I disagree. But please be clear.

If you’re arguing for the latter, then try to explain to me as simply as possible how a blockchain with “proof of authority” is better to Git with signed commits. Or CT. Or Keybase. It seems that these business blockchains are inefficient, append-only Merkle trees. It’s not particularly novel, and replicating the database across all nodes of the network and constantly engaging on a consensus protocol to agree on the state of the network while all peers are trusted anyway with proof of authority seems quite useless.

If I am wrong, then the blockchain people can do themselves a favour and make a simple comparison chart of their solution compared to possible alternatives. But I don’t think they want to do thst. I think they baffle non-technical people with words like “decentralised”, and “cryptographic signature” and polish it nicely until people believe in them. Just try reading Alex Tapscott’s book “The blockchain revolution”. I think it is snake oil. The emperor’s new blockchain.


> To be clear, what are you trying to convince me of? The target keeps moving. Are you trying to convince me that a blockchain is needed instead of Git for a currency like Bitcoin? In that case I agree. In fact I conjecture that blockchains are only useful for cryptocurrency. Or, are you trying to convince me that a blockchain is useful for businesses for something like “the supply chain” or whatever, without any cryptocurrency? If so, then I disagree.

I just went on explaining why you want to use a blockchain (private or not) instead of git. It's a broad question so you'll get a broad answer. This is the only thing I went into:

> Exercise for the blockchain advocates: explain as simply as possible why a “private blockchain” is better than Git.

I haven't talked about anything else. If you want to know what people think about using blockchains for A and B, you should ask that instead. My target hasn't moved at all.

> try to explain to me as simply as possible how a blockchain with “proof of authority” is better to Git with signed commits.

I specifically explained where an append-only merkle tree doesn't cut it in the comment you just replied to (my previous one). Note that git is an append-only merkle tree. You are more than welcome to go into my points.

> It’s not particularly novel, and replicating the database across all nodes of the network and constantly engaging on a consensus protocol to agree on the state of the network while all peers are trusted anyway with proof of authority seems quite useless.

If all peers are completely trusted you are 100% correct, if you trust everyone completely you don't need a blockchain. However in the real world trust isn't binary. If a bunch of banks KYC each other and go into a blockchain consortium, they do this specifically because they don't trust each other enough. Else they would have gone with a straight forward solution like git a decade ago.


You talked about bitcoin. That's entirely different to a "private blockchain". So that is why I think the target keeps moving in this conversation. Or are you suggesting proof of work or something? If so, then I am exiting out of this conversation :-)

Anyways, perhaps a better exercise to clarify would be: Find a single example where a (precisely defined) type of blockchain makes sense vs possible alternatives such as solutions along the lines of Git, CT, etc. I conjecture that there are none beyond cryptocurrency.


> You talked about bitcoin. That's entirely different to a "private blockchain".

I never said they were the same, however the similarity is that they are both blockchain systems. And you cannot achieve the same with git for exactly the same reason (you cna't trust all parties).

> Or are you suggesting proof of work or something?

Nope, definitely not. Not sure what made you think that?

> Find a single example where a (precisely defined) type of blockchain makes sense vs possible alternatives such as solutions along the lines of Git, CT, etc. I conjecture that there are none beyond cryptocurrency.

There are loads all over commodity trade finance and supply chain (the field I have experience). But I've spend an hour typing an answer out your initial question:

> Exercise for the blockchain advocates: explain as simply as possible why a “private blockchain” is better than Git.

And now you state you aren't really interested in that explanation and want to have clarification on something completely different.

I'm done with typing out "examples and clarifications" when as soon as I do you start asking a different question, never going into my points. So "I am exiting out of this conversation :-)"


I know why you would use a blockchain: for cryptocurrency like bitcoin. As I say, I conjecture there are no other applications.

You made me think you might be suggesting some proof of work scheme instead of "proof of authority" because the example you chose was bitcoin. You also said: "You need to align incentives in a way that breaking the complete system is infeasible from a financial point of view.". So that's why I thought of it. Apologies if I was mistaken.

I don't quite understand why this conversation is getting heated for you. Perhaps because it is your career so you feel personally attacked or something. That's not my intention. Anyways, I'm still none the wiser as to why to use a "private blockchain". Blocking commits or whatever isn't really solved by a private blockchain. You don't need a blockchain for the problem of changing the order people said things either. And how many banking consortia were really moaning about these issues before a blockchain came along? A blockchain seems like a solution looking for a problem most of the time.

Comments like this:

> Blockchain proponents say that once you have a stable decentralized system that can run any code and cannot be corrupted in any way, you will see innovation flourishing similar to the internet: the internet brought complete freedom of information (and industries build on top were not imaginable in the 80s), some people think the blockchain will bring freedom to anything that is (or should be) scarce. Like money and commodities.

Comparing blockchain to the internet? I think that is just crazy la la land. I really hope I'm wrong because that sounds amazing. (Although I have no idea what "that" is, but the internet was a good thing and I like good things.) But I'm definitely not.

But anyways I agree with you that we should stop.


Not going into the topic, just the discussion itself.

I'm totally fine, hope you are too. I don't feel personally attacked at all. But on the internet a thick skin is required. I hope you don't feel attacked either.

> Anyways, I'm still none the wiser as to why to use a "private blockchain" but I agree with you that we should stop.

That's unfortunate, I hope you do understand one day. I won't go into it now since you started with a different question (or technically an exercise). And after my lengthy attempt in explaining it you expressed that you don't actually care and instead ask questions about consensus algorithms used in different blockchains (like PoW and PoA) - which has nothing to do with why one uses a blockchain and not git.

So please next time if you are interested in something, don't start by asking something else. After that trying to steer the conversation towards your hidden objective all while you are accusing the other side of "moving the target" (you are moving the target from git towards consensus algorithms and blockchain use cases).


I hope I understand too. I hope blockchains become as useful as the hype suggests. But I bet my career on it that it won't. Let's set a reminder for 10 years and see what happens? :-) We could bake a bet into a smart contract. (Actually we probably couldn't.)


Honestly I'm also quite skeptical, I share your view.

Though I believe the deciding factors aren't very technical. For public projects it all depends on what people want (in reaction to government control, surveillance, financial and capital controls)

And for private blockchains in my experience (in finance anyway) it all depends on the regulators and what they will allow. They are also reacting to whatever is happening in the world.

Currently it all looks pretty bleak indeed.


id say because it’s a tool purpose built to provide a distributed ledger between untrusted (or in this case semi trusted maybe) parties... git is not a tool thats built for that. if you reverse the argument, explain why git is a better solution for a write only, transactionally consistent, distributed, trustless ledger. i’m sure you could make something akin to a blockchain with git, but why would you when we have a perfectly viable solution that’s prebuilt for the purpose.

they both might be able to perform similar functions with enough customisation, but a blockchain is fit for purpose out of the box.

note: i’m thinking here a blockchain with POA where tokens are distributed between known parties, so no overhead of POW. POW has very obvious down sides


Git with public/private keys is literally that. I don't understand why there's hype around blockchains.

Besides, how can people say a private blockchain is "trustless"? You just said "POA" ( = proof of authority). The conversations I often got into at my job were like this. It was so incredibly difficult to pin down exactly why they even wanted a blockchain. Or what a blockchain even was in their heads.


It's only a little more than that:

Git (or a DAG) + priv/pub keys + Proof of Work = blockchain

If you remove "PoW" it is just "signing in git". Which is an interesing and complex thing.

And it being private removes all the need for PoW or removes the function that PoW fulfills. So a "private blockchain with PoW" is really stupid and (even more so) a waste of energy.

Whereas a "private blockchain without PoW" is "just git".


Haha yeah, it's comical how crazy the hype is.

1. Blockchain was this clever solution related to money. Anonymous person invented it. Some news about crime around it. Lots of money around it. So blockchain is this money thing and technology thing? Sounds kinda sexy.

2. Business people heard about it, thought it might be The Next Big Thing. Ask boffins to investigate.

3. Other business people heard their rivals think blockchains are The Next Big Thing so they need to get on it too.

4. hmmmm, turns out a business is mostly all about being centralized which is at odds with a boockchain. hmmm it's actually kinda uselsss? Maybe we can get rid of all the bits we don't like about it? oops we just reinvented the wheel.

A "private blockchain with proof of authority" is like cutting the hump of a camel and calling it a horse. Just use Git.


There is much hype. However, as someone who was at least as skeptical (and cynical) as you a few months ago, but (somewhat accidentally) has ended up working this this space, and for cognitive dissonance-reduction reasons, has had to figure out what's real and what's hype (or just plain lies), I have to say that I don't think it is all as bogus as you perceive.

>A "private blockchain with proof of authority" is like cutting the hump of a camel and calling it a horse. Just use Git.

This sounds clever, but it isn't right: Git has no equivalent to consensus for transaction correctness, for example. It has no equivalent to smart contracts. It has no peer discovery mechanism. It has no automatic transaction propagation mechanism. And on...

Executive summary : "there may be a pony in there somewhere"


We sound quite similar. I also accidentally ended up working in this space a few months ago and started off incredibly cynical (my first meeting telling everyone there I don't think there are any useful applications relevant to the business whatsoever). Looks like I went one way (getting out and doing something else) and you stuck around :-) I hope you are right and the technology is actually useful for humanity. I hope I'm wrong, but I don't think I am.

I conjecture that blockchains have no applications beyond cryptocurrency. I hope someone can give me a very simple counterexample. I've seen blockchains for the music industry, for porn, for university, for bananas in Laos, for weed, for voting, for "supply chain" something or other. I've never seen an application explained simply that makes sense. I am highly skeptical of the field.


imho the thing you're missing is that "consensus" is more than just "which txn followed which in time". For example : in Bitcoin a txn is not valid unless the sending address has sufficient funds. So nodes are checking not only the things you're thinking about, but also "is there enough money for this?". Git does not do this. It would be as if Git not only took whatever commit you sent it, but also checked that your commit compiled and passed tests, before it accepted it.


But that part has little to do with "a blockchain" and everything with how that blockchain is implemented in a specific currency.

The storage part of the transactions is suprisingly simple and is what makes up the blockchain: the PoW, DAG and signatures of all that: PoW + git + pub/priv signatures.


This is a good exercise that the other answers fail at the twist.

Git is a blockchain, and sometimes a private one.


Yes, this is what I expect to happen.

1. Satoshi comes up with this clever blockchain thing with proof of work and hashing and append-only characteristics. It solves a very specific problem.

2. It involves money and new tech so business people get on the bandwagon and tell the boffins to investigate.

3. There's a lot of hype and good publicity for it (e.g. KodakCoin, Long Island Iced Tea Blockchain)

4. The technology as Satoshi defines it is actually pretty useless for their application. So they bend the definition slightly. Blockchain becomes Git or something with a signature or hashing or even a Merkle Tree.

5. Git etc is actually useful sometimes. The blockchain prophecy is complete. The business people are happy. The boffins don't do anything really, but everyone gets paid so nobody really cares.


Blockchain definition from article: a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions

Context from referred Nakamoto pdf: In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions

So this is not definition of blockchain by Nakamoto (There is no term blockchain at all in this pdf)

Definition from wikipedia (I agree with): A blockchain is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a merkle tree root hash)

From this definition git is also kind of blockchain.

So its hard to follow article with such vague definition from start.


> Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data

This thing, however, exists only for the purpose of solving decentralized trust problem and cannot be secure without a popular public cryptocurrency. Hence private blockchain is a fallacy. If trust relies on authority it's just a weird database, not a "private" blockchain.

It's similar to how people were annoyed with the commons clause added to an open source license being associated with the same old unrestricted license, that in fact became a completely different license.


There is, this though.

> chain of hash-based proof-of-work

and

> chain of blocks

in this paper. His later communication does call this "block chain".

So you are right that he/them/she does not use the term "blockchain" in the paper. Nor "block chain" but the term can be extracted from there clearly.


It's a good time to point out that "permissioned" blockchain does not have to mean a "private" blockchain. While the validator nodes may be a whitelisted group, anonymous users can still be allowed to run observer nodes.

This is the approach the erstwhile InterPlanetary database was planning to take. IPDB shut down earlier this year. Some of us really wanted this so we're setting up an Ethereum-compatible, permissioned+public blockchain called Indium.Network: https://indium.network/


Honestly curious what that solves, and how that would work.

If it is permissioned, does that not essentially mean its write-side is "private"?

What can an observer now do in case the whitelisted entities decide to change history, other than tweeting about it? I'd argue that if the observer now has power to eject the rogue entity/ies from their power, it is a public system. Just via a separate layer.

And if it is permissioned, does that not automatically mean it is centralized?


>If it is permissioned, does that not essentially mean its write-side is "private"?

Not parent, but yes.

>And if it is permissioned, does that not automatically mean it is centralized?

That depends on your definition of centralized: if you mean "under the control of humans" then yes it does. If you mean "under the control of one human" than no it doesn't.

For example a common approach is to designate a set of institutions (e.g. not for profit foundations in several different countries) to be in control of the validating nodes. Under that model a quorum of those institutions would need to be subverted in order to censor transactions.


Yes, "non-profits with political, jurisdictional, legal diversity" is pretty much the approach we plan to take. In fact, to begin with we'll be borrowing from Sovrin (decentralized identity)'s governance model.


I consider a consortium of individuals "centralized". At least not "decentralized".


> It's a good time to point out that "permissioned" blockchain does not have to mean a "private" blockchain. While the validator nodes may be a whitelisted group, anonymous users can still be allowed to run observer nodes.

So I guess that means certificate transparency is a "blockchain"?


For most companies, securing funding and getting exposure in the media is significantly more important than using technically correct terminology to describe the implementation details of their product.


Interesting logic. The author quotes Satoshi's definition of blockchain which doesn't preclude private blockchains at all.

He then quotes a "more accessible" definition that explicitly precludes private blockchains. So fine, if you define blockchain as being open then, sure, it can't be private.

He then has a flowchart that doesn't refer to either definition and follows that with a set of reasons why people want a private blockchain and refutes them. Two of these are fine: private data and access control. Two of these are just plain strawmen: scaling and confidence.

And of the 2 reasons that do make sense he makes clearly incorrect statements:

> A blockchain has to be public in order to ensure permanence or immutability.

No it doesn't. A restricted group of people can use identically the same features that a public blockchain has to manage eventual immutability. If that weren't true then it would imply that, say, the Bitcoin blockchain would not have it's current immutability properties if only its current users could access it. But that's simply not true.

> A blockchain has to be permissionless in order to ensure permanence.

Again, no it doesn't. Just because you restrict who writes to the end of the chain says nothing about the rest of the chain.

Now, it would be a reasonable argument to say that the useful properties of a blockchain are only available to people who have read access to the whole blockchain. And I'd agree with that. But he's not making that argument, as far as I can see, so his actual argument is either tautological or verifiably wrong.


> the Bitcoin blockchain would not have it's current immutability properties if only its current users could access it. But that's simply not true.

Interesting point. But I think this evolves around what makes "private" and what not. Is a network of ~10.000 anonymous nodes "private" if you now close it? I guess it would be called "permissioned" and not "private".

Further, my point is that when you would close the current network and disallow anyone to write and read from it, other than the currently online ~10.000 nodes, disallow new wallets and participants (making it private) you'd loose three things, essentially rendering the blockchain unusable: breaking it's immutability:

* There would be no new miners.

* There will be no increase in usabiltity: no future gain.

These two things will logically cause centralisation of the existing mining. After all: no new miners can join, and only miners can drop out.

A typical "private blockchain" so not one that started out public, grew large and then turned private, but one that starts out private, therefore has no need for PoW at all: it makes no sense, and adds no security that is not already there (through enforcements of access controls). Hence either the PoW is just nonense and (even more so) a waste of energy. Or it is left out.

And a blockchain without a PoW is just a DAG tree. Or cryptographically signed logbook.

Which can be useful in itself. But which is not a blockchain.


I think there is a space for private (or permissioned) blockchains and there are a few techniques that allow such a chain to inherit the trust of a public blockchain such as Bitcoin or Ethereum (side-chains, Plasma, etc) so that it's possible to use cryptocurrencies or other popular tokenised assets in a private setting without users having to trust the owner of the private chain itself.

In such scenarios, the role of block producer is centralised and limited to the owner of the private chain which means a less power-hungry consensus mechanism such as Proof of Authority can be used and have block interval times in the milliseconds.

A project I've worked on recently aimed at delivering a similar solution in a global company that has historically grown through acquisitions and mergers where the IT systems never fully integrated, meaning that despite operating under the same name, there are hundreds of BUs that don't "trust" each other.


I loved Doré Woodcut. Its only function is to make the layout look better. And these images are really nice themselves


There's a similar flow diagram in a 2017 paper titled "Do you need a Blockchain?" [1] which identifies 3 types of blockchain:

* Permissionless Blockchain

* Public Permissioned Blockchain

* Private Permissioned Blockchain

[1] https://eprint.iacr.org/2017/375.pdf


I (author) have read this paper, and think it is only partly correct.

However, the article describes a lot of examples that are clearly not blockchains, but cryptographic interesting solutions like a ledger that gets distributed amongst all observers. It even often concludes that "this is not a blockchain". But then goes on to call it "blockchain solutions like this".

If the paper would stop abusing the word "blockchain" for "anything with cryptography", and instead use more precise terms, it would be a very good paper. And it would underwrite what I am trying to say:

There's loads of interesting data-structures to solve many interesting problems that industries have. Lets' call them what they are instead: DHTs, DAGs, Merkle Trees, Pub/Sub buses, etc.


I think this is semantics, many people are talking about distributed ledgers more than Blockchains specifically.

"A distributed ledger (also called a shared ledger, or distributed ledger technology, DLT) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites, countries, or institutions." [1]

[1] https://assets.publishing.service.gov.uk/government/uploads/...


But is a "distributed ledger" a blockchain?

Nowhere in my article did I say that "private distributed ledgers" are nonsense (allthough, writing it down gives me cringes).

But the whoe focus on "terminlogy" is in my article for pricesly this reason. I am not talking about how it is silly to have your excel sheet shared amongts a predefined set of participants using fancy bittorrent-streams (a distributed ledger).

But that a blockchain being private is nonsense.

And allthough your average marketing department might hate to hear it, but your distributed ledger is quite certainly not a blockchain.


So, I guess a shared Google Sheet is a distributed ledger?


Looks like another overly simple blockchain article. The author lists a bunch of reasons why someone might want to use a private ledger and then dismisses all of them without any argument. Here's a whole bunch of reasons why private ledgers make sense in some context:

- Control read / write - A list of companies in a consortium might like to maintain shared settlement resources but don't trust a single party for consensus. A private ledger offers a genuine improvement in security over other technologies during a breach. I.e. imagine if there are machines being controlled by authorized humans working with contracts on the private ledger. Hacking a few servers there isn't going to compromise the contracts which is really cool.

- Scale better (scrap the distributed part) - Some of the newer ledgers are doing exactly that. When you cut node count it does reduce decentralization but the trade-offs are on a gradient. Again, not necessarily an incorrect choice. Look at something like Ricardian contracts on Corda for settling bank deals. The actual "settlement" isn't done on the ledger at all. All that occurs on Corda is a beautiful way to craft financial contracts that will be easier to audit by regulators. Private ledgers all help with that and would benefit from not using an entire flooding-based p2p network to do it.

- So we can store private data - There are many companies and institutions that need to store private data. One can imagine advertising companies sharing demographics or hospitals sharing medical records. There's nothing novel here about acting as a database. What the author fails to grasp are some of the more subtle aspects of distributed ledgers. Like the more nuanced trust relationships between companies or business requirements (upgrading old technology, sharing the costs, incentivized standardization.)

Caveat: distributed ledgers are not blockchains. But my problem with this article is the blockchain fanaticism mixed with the authors seeming inability to think outside of black and white terms. He dismisses everything about enterprise ledger technology that doesn't fit in his narrow definitions and can't see any of the nuances of using them. The result is a person who fails to understand either public blockchains or private ledgers very well (like most people it seems.)


> distributed ledgers are not blockchains.

Author here. Thanks for your criticism.

I think you are making my point too. And you do touch on the reason why I focused so heavily on the "terminology part".

What irritates me, is that anything "crypto" is suddenly called "blockchain". Signing transactions and including a pointer to a predecessor is not a blockchain, it's a DAG and we use it daily (git).

"Distributing your data" maybe even using merkle trees, is not a blockchain. Its "distribution". An interesting and broad subject in itself. Distributing a ledger is hardly new, though still a field very much in motion.

All the things you describe are really very interesting fields often tremendously complex.

They all usepieces of tech found in a blockchain too. But then again: the whole basis of bitcoin is really just a combination of existing tech put together in a novel architecture.

Many of the things you describe (like distributed ledgers) require quite novel concepts and most of all leaning heavily on cryptography. But none are "blockchain".


Contrary to what is claimed in the final section, BitTorrent is not actually an implementation of Merkle trees.

Because there are no trees.

The hashing used in BitTorrent metainfo files works by splitting the concatenation of all constituent files into equally sized blocks, individually hashing each block (using SHA1), and concatenating the hashes. Paths and sizes for all the files are also stored, but separately from the hashes.


Isn't this all definition?

It seems reasonable for three companies to create a block chain only they see. It is public, in a sense, because the transactions span different trust domains. It is not public because it is not on the open internet like Bitcoin.

Multi company blockchains are the primary use I know of the term 'private blockchains'.

I don't see anything in this paper which argues against this...


Well no, because for these cases the most important thing that a blockchain solves needs not be solved.

PoS (or PoW) are not needed because there is no sybil attack nor a byzantine-general problem to be solved. In fact, most "Private Blockchains" ditch the PoW and therefore can claim "tremendous scaling" or things like that.

Ditching the PoW solves most of the scaling issues. Sure.

But a blockchain without a PoW is simply a log that is cryptographically signed (but not secured). Because I could very easily just change block #2 and simply accept the cascading effect. People familiar with Git use this principle every day. A git --amend and git push --force is exactly this.

Once you can convince the participants in your private network (your colleagues) to use your branch, history has been rewritten. (And the old work is just one garbage-collection away from being forgotten forever).

So, yes, it is very much a definition question. But that is because "a blockchain" has it's requirements and its pro's and cons built into that definition. So if you start stretching the definition, you simply loose requirements. And you end up with something that really makes no sense.


As much of a fallacy as "personal cloud" (the new marketing term for NAS).


Please correct me if I am wrong - but when people say private blockchain I think they mean multiple nodes that don't trust other, but not an unlimited number of nodes or the ability for just anyone to mint coins upon it.


The majority of the time I see the term "private blockchain" used it's in reference to something not dissimilar to a few companies keeping an append-only ledger.

In that case, each company is trusted to at least be authoritative for their entities and to be trusted to the extent that their identities are known and they may be held accountable.

In that situation, an append-only log with merkle-tree-like crypto could handle the situation just fine.

The key thing that isn't needed there is proof of work; participants do not need to be "rate limited" and, if a conflict arises, they can all be trusted to, say, arbitrarily pick the item with the lowest sequence number rather than needing a proof of work system.

In what situations do you think a private blockchain is warranted and specifically why is proof of work necessary in that scenario?


Blockchains have consensus built in at the protocol level. Sure, you could share an append only log, but who settles disputes? All that functionality has to move off chain, and that's a bigger risk, in my opinion.


> Blockchains have consensus built in at the protocol level

They have it built in based on picking the chain which the most work has gone into.

Arbitrarily assigning a number to a transaction and having everyone to agree to pick the smallest in the case of conflict is easier and works fine if your members are all trusted to not maliciously abuse that facet of the code.

Proof of work is throwing away resources to solve a problem you don't have if no one is crafting malicious transactions.


>Arbitrarily assigning a number to a transaction and having everyone to agree to pick the smallest in the case of conflict is easier and works fine if your members are all trusted to not maliciously abuse that facet of the code.

This would be like a traditional eventually consistent distributed database (using total order to resolve conflicts).

And we might ask "why did those deploying private blockchains not just use that kind of thing?".

I'm not sure, but potential reasons are:

1. That kind of thing doesn't actually exist in a form that they can easily use, so they re-purposed existing, reasonably proven blockchain technology to achieve an equivalent functionality.

2. The parties don't completely trust each other so in fact malicious transactions can be crafted.

3. They don't trust their software to not craft malicious trasnsactions and the blockchain provides a neat way to filter them out.


Don't forget about potential reason number 4.

4. Blockchain is very hyped right now and they want to show that they are hip and cool by keeping up with the latest trends.


Proof of work is but one consensus algorithm. There is proof of stake, proof of authority, delegated proof of stake, etc. Dozens of different approaches out there different from Bitcoin.


but why would you? blockchain is a fine solution; why reinvent it? replace POW with POA and there are very few reasons not to use a blockchain here


Because you are literally wasting resources (PoW/PoS) to resolve conflicts that can be resolved much simpler.

And to protect against sybils that cannot exist by nature of being private. Or to protect against Byzantine nodes that cannot exist by the nature of being private.


Let's say the OP is correct. It doesn't matter — Whomever is using the word is using it how they want to and the recipient will understand the correct and incorrect meaning. If I was the CTO at a bank and I told the OP we were building a private blockchain for asset management, he would know what I mean. Now since the op is technical, he would probably ask more questions to figure out that what I really want is an openly audit-able immutable database, but his intellect would allow him to drill down further.

This fallacy the same thing that happened for the word "Disrupt"/"Disruption"/"Disruptive Technology". Even Clay Christensen, the creator of the phrase, says most people misuse the phrase "disruption" when compared to his explanation in the Innovators Dilemma[1]. There are Tons[2] of[3] people[3] complaining that the term is misused. In the end, if you casually tell someone you've got an idea for a Taco Food truck that's going to disrupt the food truck industry, people will know what you mean.

The definition of this word "blockchain" is being misused so much that it is changing faster real eduction can help. I think posts like this are great if you're technical, but as I said above — It doesn't matter what the fallacy is.

[1] - https://www.amazon.com/Innovators-Dilemma-Revolutionary-Chan...

[2] - https://techcrunch.com/2013/02/16/the-truth-about-disruption...

[3] - https://www.forbes.com/sites/vukivujasinovic/2017/03/02/its-...

[4] - https://www.newyorker.com/magazine/2014/06/23/the-disruption...


If it's private, it isn't auditable. You can keep a journal of all transactions, and when you decide that history needs to be changed, you make the change in your journal and roll it forward from there. If the auditors have half a clue, you can't do this for events that happened before the most recent previous audit, but if they have a whole clue, they won't accept the current state of your system as anything more accurate than your attestation.

The counterargument to "words mean what people agree they mean" is that "to computers, instructions mean what they have already been defined to mean". If you change Python's meanings, you need to tell everybody that you're using Python 3.5-Joe, not Python 3.5.


>If it's private, it isn't auditable

Clearly true, but in this field "private" is really being used to denote "not a Public Blockchain like Bitcoin and Ethereum".

It doesn't mean "actually private". It means "we built our own rather than pay to use Ethereum".


No, because that would be another public blockchain.

Private really means what you think it is "a blockchain that only a small selected group can access". A lot of "Private blockchains" are just Ethereum-nodes running behind a firewall and with a secret genesis-block.

It does not, however, mean that it cannot be peer-reviewed. Allthough that still leaves the problem of not knowing if what you've reviewed is what is running.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: