People treat blockchain as a "futuristic integrity wand"—wave a blockchain at the problem, and suddenly your data will be valid. For almost anything people want to be valid, blockchain has been proposed as a solution.

It's true that tampering with data stored on a blockchain is hard, but it's false that blockchain is a good way to create data that has integrity.

To understand why this is the case, let's work from the practical to the theoretical. For example, let's consider a widely-proposed use case for blockchain: buying an e-book with a "smart" contract. The goal of the blockchain is, you don't trust an e-book vendor and they don't trust you (because you're just two individuals on the internet), but, because it's on blockchain, you'll be able to trust the transaction.

In the traditional system, once you pay you're hoping you'll receive the book, but once the vendor has your money they don't have any incentive to deliver. You're relying on Visa or Amazon or the government to make things fair—what a recipe for being a chump! In contrast, on a blockchain system, by executing the transaction as a record in a tamper-proof repository not owned by anyone, the transfer of money and digital product is automatic, atomic, and direct, with no middleman needed to arbitrate the transaction, dictate terms, and take a fat cut on the way. Isn't that better for everybody?

Hm. Perhaps you are very skilled at writing software. When the novelist proposes the smart contract, you take an hour or two to make sure that the contract will withdraw only an amount of money equal to the agreed-upon price, and that the book — rather than some other file, or nothing at all — will actually arrive.

Auditing software is hard! The most-heavily scrutinized smart contract in history had a small bug that nobody noticed — that is, until someone did notice it, and used it to steal fifty million dollars. If cryptocurrency enthusiasts putting together a $150m investment fund can't properly audit the software, how confident are you in your e-book audit? Perhaps you would rather write your own counteroffer software contract, in case this e-book author has hidden a recursion bug in their version to drain your ethereum wallet of all your life savings?

It's a complicated way to buy a book! It's not trustless, you're trusting in the software (and your ability to defend yourself in a software-driven world), instead of trusting other people.

Another example: the purported advantages for a voting system in a weakly-governed country. "Keep your voting records in a tamper-proof repository not owned by anyone" sounds right — yet is your Afghan villager going to download the blockchain from a broadcast node and decrypt the Merkle root from his Linux command line to independently verify that his vote has been counted? Or will he rely on the mobile app of a trusted third party — like the nonprofit or open-source consortium administering the election or providing the software?

These sound like stupid examples — novelists and villagers hiring e-bodyguard hackers to protect them from malicious customers and nonprofits whose clever smart-contracts might steal their money and votes?? — until you realize that's actually the point. Instead of relying on trust or regulation, in the blockchain world, individuals are on-purpose responsible for their own security precautions. And if the software they use is malicious or buggy, they should have read the software more carefully.