Ask HN: What are real-life useful use-cases for blockchain (not currencies)?

> Wouldn't sending a copy of the photo to the owner prior to transportation be sufficient?

Doesn't protect against the owner saying you didn't send the photo, or that it didn't arrive in time, ...

> Actually, why doesn't the owner take a picture himself?

Because they're not present when the car gets transferred between transportation companies.

Yes, that's the entire point. It's a digital thing that, at significant expense to run the system, nobody can forge a copy of.

I find that there is a reasonable percentage of people here that look at what problems it actually solves versus handwavey marketing magic. It's fanboy chat groups where I would expect the discussion of whether it's actually useful to be avoided (or be overwhelmed by those with skin in various kinds of blockchain game), but I'd be happy to be wrong. Why not link them if you say there is better content available elsewhere?

Certificate Transparency is mostly built out of a Merkle tree hash which is a 1979 idea from Ralph Merkle (also the M in MD5 and various other things) and ordinary digital signature technology of the same sort used in those certificates.

An observer can verify that the log remains consistent (thus nothing can be retrospectively inserted or removed as opposed to appended - without an observer detecting this) and that specific things that carry SCTs saying they were logged were, in fact, appended to the log.

This isn't a blockchain. If you want to call it "blockchain technology" you can probably squint hard enough to do that, see also various "Internet technology" companies from the turn of the century that just consisted of a normal company plus a web site most of which were failures - but I don't think you learn anything from it.

And in fact not all of CT is actually finished and deployed. There ought to be a Gossip system, which would allow clients to er, gossip about things they'd learned, and thus discover any inconsistencies which they can't see individually. e.g if from Turkey the log seems to show one entry for this www.google.com certificate but when seen from France the entry is different, Gossip potentially allows a Turkish client to tell a French client what it saw and the alarm is sounded. Gossip is necessary to ensure logs can't deliver a split horizon view and to loop back the trust from SCTs to actual log records, but it's fraught to do this in a privacy-preserving manner.

The actual deployed system works for two reasons, which I've no doubt would horrify Blockchain proponents who worship at the altar of distributed consensus:

1. The actors (root Certificate Authorities, trust stores) are basically honest. They're not always competent or diligent or open but they mostly don't deliberately spread falsehoods, so the records in CT would probably be almost as useful even if it was just a huge text file or something with no cryptographic basis of trust.

2. The main clients mandating CT are Safari and Chrome and both of them require that certificates are logged with Google (and somebody else, but you can pick who). So attacks that require falsifying the logs can't work unless Google does them. If you're Google this is enough. If you're not Google it's still pretty satisfying, why would Google build this complicated and relatively expensive system just to lie to me about something I otherwise would have no way to know about in the first place?

In the long-term, I think blockchains will make a major showing in the design of self-driving vehicles (SDVs).

For SDVs to really take off, it needs to surpass the safety of a human driver but the only way to do this reliably in a way that avoids the high costs and ugly protrusion of roof-mounted LIDARs is for SDVs to use low-cost internal sensor inputs and fallback on low-cost external sensor outputs from nearby vehicles[§] and road infrastructure.

Essentially, what I think is missing from all SDVs currently in development today is an important ingredient behind why Internet-use is so widespread today: a common communication protocol between SDVs from different manufacturers.

Once a common protocol is adopted/legislated, all SDVs will be expected to record any accidents encountered during any trips in a partial copy of the “road blockchain”. Stated differently, details of accidents and near misses will be recorded with timestamps on the partial blockchain maintained by each SDV in a way that the exact position of all SDVs within the vicinity of a car crash can easily be reconstructed. Of course this will mean SDVs will use clocks that are network synced.

If 6 cars are in the vicinity of a crash between 2 cars, the trajectory of all cars before and after the crash could be reconstructed using the blockchain data from those 2 cars. If the 2 cars’ “black box” are lost due to them exploding on impact, the data could still be reconstructed using the partial blockchain data from the 6 SDVs proximate to the crash.

The “road blockchain” would be especially useful in accident investigations but its privacy implications would need to be properly thought out.

§: If a SDV has front sensors that start to return conflicting inputs while in operation due to inclement weather for instance, rather than the onboard computer aborting the ride in the middle of nowhere, it could switch to operating at partial instead of full situational awareness. In this state it could routinely query any three nearby vehicles for help: the vehicle in front, behind it & to its left to regain some level of situational awareness.

Another use case would be falling back on wireless beacons when Internet access over cellular is lost. The SDV could start an adhoc network over wireless where it can broadcast a request for help from nearby SDVs. Something like: “I’m traveling from LA-SF. I need a recent copy of the point cloud from anyone traveling in the opposite direction (SF-LA)”.

For this to work at scale, a common protocol that allows a SDV to start a wireless conversation with any nearby SDVs would be required.