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)?