This isn't why you should use the blockchain, but I do see one concrete useful scenario for it: keeping track of things like shipments between companies that don't trust each other.
As goods move around, if you receive a damaged or bad item, you have an immutable, easily accessible paper trail of claims that people have made about the good.
It solves the oracle problem by sidestepping it: what is on the blockchain isn't truth, but verifiable claims various people have made about the truth. Easily accessible for lawyers in resulting lawsuits.
It is also something that's actually very hard to solve with a traditional database in a centralized manner, because then you have to trust whoever runs the database to not falsify records.
It also doesn't suffer from a lot of issues that public blockchains like cryptocurrencies face, like limited transaction volume or warming the earth for mining.
There might be other reasons why it wouldn't work out, but it seems like an actual useful tool there.
> Certificate logs are append-only ledgers of certificates. Because they're distributed and independent, anyone can query them to see what certificates have been included and when
That sounds like a blockchain? In the same sense that a git repo is also a blockchain.
At any rate, from what I can tell from reading that page, that's the sort of thing I'm talking about.
What does a blockchain add over simple PKI? The latter is far more efficient and it can run offline so you’d have the possibility of, say, a factory or farm giving something to a truck driver with limited or even no network connectivity — something like a Yubikey could do the crypto more securely with the power budget of a solar cell.
In your example, how do you handle updates when a certificate expires or needs to be revoked? The Yubikey won't have internet with that power budget, so you'll have to manually update it.
Whenever you update the Yubikey, just update it with a snapshot of whatever certificates you care about from a blockchain like the link above. The Yubikey itself doesn't have to be a fully-participating node.
That's certificate transparency, which few blockchain proponents seem to consider a blockchain — and the developers of Trillian definitely don't class it as such as per https://transparency.dev.
I think that is a useful concept and that's not terribly far out of line with what I was proposing — the main idea was that the useful part is basically the chain of signatures for a transaction but that it's only worth so much infrastructure because so much of the system depends on real-world activity outside of it. If my driver signs receipt of your goods by having both of them wave a key over a phone, that is useful information but there's a cap on how much value you can see from it because it doesn't say whether those statements were honest. The types of blockchains proponents outline are too expensive for that but something like what CT does could be useful — the key part being that it's kept small, efficient, and allows offline operations to handle limited connectivity.
As goods move around, if you receive a damaged or bad item, you have an immutable, easily accessible paper trail of claims that people have made about the good.
It solves the oracle problem by sidestepping it: what is on the blockchain isn't truth, but verifiable claims various people have made about the truth. Easily accessible for lawyers in resulting lawsuits.
It is also something that's actually very hard to solve with a traditional database in a centralized manner, because then you have to trust whoever runs the database to not falsify records.
It also doesn't suffer from a lot of issues that public blockchains like cryptocurrencies face, like limited transaction volume or warming the earth for mining.
There might be other reasons why it wouldn't work out, but it seems like an actual useful tool there.