What is the advantage of a private blockchain over a hash tree like used in git? A git commit is also irrevocable, except if you do a git rebase. How do you prevent something similar like a git rebase in a private blockchain?

A public blockchain with multiple agents that do not trust each other like in BitCoin make sense to me.

Think of an industry e.g. like banking, where the different participants know who each other are but don't fully trust each other. Presuming each participant controls one replica in the system, then using BFT algorithms you can ensure that so long as less than a third of the participants are malicious it is not possible to perform such an attack.

You can also set up a git repository and prevent history rewrites on the central server. Some third party could also offer this as a service. Each entity can check this by doing a pull every minute in a cron job, which fails when history rewrite happened. If they detect this, their legal department can take some actions.

Just because Encarta existed, didn't mean Wikipedia shouldn't; or because NFS exists, Dropbox shouldn't. They can be solutions to the same problem. In git's case though, it sounds more like a abuse of its underlying properties (not to mention, you'd have to block all git commands that can rewrite history).

> not to mention, you'd have to block all git commands that can rewrite history

Okay, so use mercurial or fossil.

Don’t signatures get you the same benefit? I don’t need to trust you simply to sign something saying “user X showed me hash Y at time Z”.

Signatures still requires a centralized entity to manage the trust. A public distributed ledger, be it a blockchain or something else do not.

We don't even have a centralized authority for x509 in browsers, and that's the closest you come to being correct — there are still many CAs and multiple groups coordinating which of those are trusted, and private CAs are common even up to millions of users.

GPG has been around since the 1990s with the web of trust being entirely decentralized and while I'd be the first to say there is room for improvement there's no way that's anything other than decentralized.

Don't a private blockchain need that anyway to manage access to add to the chain?

Or how does a private blockchain manage who has write access to it (since it's supposed to be private)?

>an irrevocable proof of record (immutability with cryptographic proof)

Which ignores and can even make worse the problem of bad data at the entry point. This is what effectively killed the entire set of use cases related to supply chain provenance.

But how can a blockchain be actually and meaningfully "public" without proof of work and distributed mining establishing majority based consensus on what _is_.

If you just store the equivalent of a blockchain somewhere then I don't see what benefit it provides over a database controlled by a consortium.

It's all bullshit.

Presumably, there's a third party that keeps a copy of the blockchain. If you rewrite the history of your blockchain, they'll detect it.

It's fair to ask why this public record needs to be in a blockchain though. You could store the record in plain HTML on a public website and have the Web Archive create periodic immutable snapshots of it.

Exacactly - you just need something equivalent to a certificate authority which signs states of the database and guarantees the correctness of the stored data.

For more than a decade, this company has been publishing their hashes in the NYTimes classified ads: http://www.surety.com/digital-copyright-protection/prove-own...

(some cryptokiddies have tried to claim it as "the world's first blockchain" https://btcmanager.com/finding-the-oldest-blockchain-in-the-... apparently not understanding how much it undermines the case for wasteful proof-of-work blockchains if a classified ad does the same job)

Okay, and what happens when I run a phony ad next to this one in the New York Times? What happens when I bribe the guy at the Times to accidentally use my hash rather than theirs?

It’s a cute gimmick, I’ll give them that.

They prove that the hash they publish in the NYTimes exists at that time. There are probably some archives which can give you an authorized copy of the NYTimes from a specific date. You can use that to prove that the hash existed at the date the NYTimes was published. This is now the hash over a hash tree, which this companies stores. With this single hash they can also prove that every document in this hash tree existed at that time. They can not add a extra document later, because this would alter the hash they published in the NYTimes.

When you publish your phony ad in the NYTimes, you also prove that this phony ad existed at the date the NYTimes was published.

This company probably buys one edition of the NYTimes with their add and check if the NYTimes published the correct hash, if it is wrong they will run an other add the next day with the correct hash the next day. Now they only prove that the hash existed the next day.

The NYTimes hashes idea is brilliant, but if you were to try to scale that concept to thousands or millions of different global use cases, eventually it seems like you'd end up with a technology platform similar to a public distributed ledger, i.e. a blockchain.

I'm open to hearing about any other non-blockchain solutions to this problem, though. One seems to be IOTA and their "Tangle" graph, but I don't fully understand how that could facilitate a historical record of each transaction, as (unlike a blockchain) it is not an append-only ledger.

That requires trusting one authority. You can do better - there are distributed algorithms that can prevent malicious behaviour from compromising the system so long as less than a third of the participants are malicious.

A blockchain requires trusting the authority that set it up and/or any authority that can 51% attack it.

If you are in a situation where you can't find any trustworthy authority (including yourself), you are probably part of a scam or a crime.

Byzantine fault tolerance is an interesting concept that solves a problem that almost never happens in modern software.

> A blockchain requires trusting the authority that set it up and/or any authority that can 51% attack it.

So, you don't understand how blockchains work, okay.

With a distributed BC you don't have to trust an authority. You trust that 51% of participating entities know what they are doing and that they checked the protocol implementation and agree on one.

A distributed blockchain has code that you have to trust.

Also you can say that everything in a blockchain is verifiable by third parties, but most people don't do that work (not unlike any open-source software).

I don't know why the comment above was downvoted. The parent clearly doesn't know what they are talking about (e.g. in a deterministic setting at most one third can be malicious).

A distributed ledger eliminates the risk that the third party hosting the record can be hacked or that the operator fraudulently lies in the record.

A blockchain does not require anything beyond ensuring the prior entries checksums make sense.

Making past entries immutable is the purpose.

Proof of work and distributed mining don’t need a blockchain.

Have you heard of hashcash? It is proof-of-work concept to prevent email spam.

https://en.m.wikipedia.org/wiki/Hashcash

what prevents the entity controlling the blockchain from recursively changing data and adjusting the checksums?

Paraphrasing Achebe here: “that until the lions have their own historians, the history of the hunt will always glorify the hunter.“

This is also an issue with a 51% attack.

Proof of work is fading away, Proof of Stake is becoming the default method.

See my answer above - in cases where the participants are all known you can use BFT algorithms to prevent attacks so long as less than a third of the replicas are malicious.