> One way of thinking about a blockchain is to think of it as a shared datastructure to keep databases in sync. Any time you want to distribute your database over more than just a single central place, in a cryptographically secure way, you're probably going to re-invent a blockchain to do it.

Even more specifically, a blockchain is for when you want Byzantine fault tolerance, i.e. you don't trust one or more of the actors involved. This is the main distinguishing feature of blockchains IMO, the reason we have proof of work, proof of stake, etc. It's also the main thing I saw people getting wrong when using blockchains during the earlier waves of cryptocurrency fever; most proposals for blockchains did make sense as distributed public ledgers, but didn't really need the extra computational overhead because only trusted parties were adding blocks to begin with.

> Even more specifically, a blockchain is for when you want Byzantine fault tolerance, i.e. you don't trust one or more of the actors involved.

Often yes. But also blockchain's can be useful simply for backups and scaling: by cryptographically linking every bit of data together you can be confident that you actually have a complete copy without any errors.

Git is basically a blockchain for this exact reason: starting from a git commit hash, git works backwards, checking that every byte of data is what it should be. Similarly, modern filesystems like btrfs use strong (if not cryptographically strong) hashes for this same reason.

Though in a sense, you're still correct: the "actor" you aren't trusting here is your own computer hardware.