Could someone tweak the image? Of course. But as a practical concern, probably less than 20 people have the image manipulation skill it would take to do something like this in the ~20 minute handoff period. The transporters certainly don't. This is a bullshit argument, and you know it. And these pictures are not just of the odometer, but the entire car, including the VIN. Photoshopping all of this believably would cost you more than just paying the damages on a joyride. It's a non-issue.

And I think you're misunderstanding something: the issue is not the time before the transporter get custody of the cars, but the many days that the cars are in transit cross-country. If the timestamp didn't exist at the time the transporter starts their journey, the next handoff knows something is up.

As for already trusting us, our clients do, yes, but the point of this solution is to increase the trust-level of custodianship handoff between people who are not our clients. A blockchain is a great solution for this, and a database is simply an inferior solution. And NO, they don't have to trust us to "push the right data on-chain". This logic runs in a very simple SPA and is immediately verifiable on-chain, without using our software, because the blockchain's global state is open.

If you're arguing to put everything in a spreadsheet, or have us control the database and do without timestamping, I don't know what to say to you. Blockchain works here. Our business model isn't changing because you're saying we don't need it. Build a system like this yourself and we'll talk about it then.

Carfax is a vertically integrated service with very little of the complexity we're dealing with. And of course you can make do without blockchain. People made do without electricity and power tools. But here it's a cheap, faster, easier to use, and more trusted alternative. What's wrong with that?

Done. It's an email server. The person shipping the car takes a photograph of the odometer, emails it to the recipient, and then the recipient compares the photograph of the odometer with the car odometer. Any tampering which could be performed on the photo or its timestamp could be done equally to whatever log is entered into the blockchain, and the recipient knows that the photo must have been taken before the date when they received the email.

And if you use gmail, it's free.

This way both parties could verify the transaction was completed as contracted (IE no joyrides).

I'm still in the camp this probably doesn't need blockchain, but that would at least handle the image manipulation problem.

But yes, depending on the application, photos can be manipulated. But that is stating the problem with using photos, not the timestamping app.

Basically, yes, you could, in theory, maybe, sort of, possibly, build a similar system without a public blockchain. But why? I'm sure there are people who can build houses with a few hand tools, but there's a reason we have power tools and heavy machinery — they are more efficient and fit the job better. The same goes for blockchain in this case.

If you can point out where my logic is incoherent, please do, but to me the following: "oh, just set up a distributed git repo or database with checksums and append-only permissions that you control but replicate to other servers not controlled by you so that you can't tamper with the outputs and read from that global state and verify against the other mirrors of the database or repo every time you read from global state" sounds like a stupider alternative to blockchain.

This is what blockchains were made for!!! Distributed consensus!

Also what is the point of mining or and proof of $whatever system? The thing your customers provide is a signed attestation of some fact and you provide a signed attestation of the time that fact was received. Why is there a need to "vote" in way on what is true? This is just a database or honestly a folder of signed messages.

And I say signed, but none of this really need to be cryptographic in any way since they're customers that could just authenticate to you which is as much a proof of their identity as any key.

The way the transporters know they're getting a fair deal is precisely because we are not the source of truth — a database outside of our control is (a blockchain, in this case).

We're not voting on what is true, we're relying on the blockchain as an immutable representation of state. An append-only, distributed database that we do not control.

And please don't downvote my comments out of a misunderstanding. That's juvenile.

This is a trust problem. Either people trust you, or they don't. You've attempted to increase their trust in you by creating a system that would increase somebody's trust if they had your understanding of the underlying technology. Very few people have this, and the overlap between the people with that understanding and your customers and clients is vanishingly small.

Trust really isn't binary.

> would increase somebody's trust if they had your understanding of the underlying technology.

Or if they had a handwaivey "I've heard that blockchain increases the verifiability of things" level of understanding.

In this specific example, what would they change to photo to? The case is to stop joyrides. Who would be able to take a joyride and end up with the odometer exactly as they had Photoshopped it to hours or days ago?

But yes, depending on the application, photos can be manipulated. But that is stating the problem with using photos, not the timestamping app.

I'm not discouraging you. Just to say your blockchain backed solution is a fair solution but it's not the only solution.

It would require cooperation from auto manufacturers but I'm sure you could come up with a scheme where the car itself signs and timestamps mileage data.

But in this case, isn't whoever controls your code the "timestamping party"?

Looking at two examples:

A: With blockchain

The timestamp that the photo was taken is immutably, publicly logged.

B: Without blockchain

The timestamp the photo was taken is logged by you, the software provider.

What is a scenario where (B) is less secure than (A)? In both scenarios, you have no proof of when the photo was taken. It could've been two hours or ten minutes ago. There is no way to digitally verify it.

So it sounds like all you're doing it creating a public, verifiable record of something that you have no incentive to alter and something that doesn't actually verify the state of the vehicle at any point in time.

From personal experience, the most common types of fraud in this space are (1) just posting an old photo as though it were taken right now, and (2) posting a photo of a different vehicle. I don't see how either of these are prevented.

What am I missing?

(Full disclosure: I built software that does something similar for different types of clients, so I've worked on the problem of "verifying vehicle state" for ~10 years.)

    When was it taken?
    Who was taking the picture?
    What is the picture of?  The car to be protected? Or someone else's car.

> When was it taken?

We currently verify this by including the last Bitcoin block hash in the photo, giving us a ~10 minute time window in which the photo was taken. Also, the whole handoff period is under 20 minutes, so the transporter only has access to the cars for 20 minutes (with many others around), before a timestamp is required.

> Who was taking the picture?

We've never run into this as a problem, but we can require a continuous video including a selfie of the transporter.

> What is the picture of? The car to be protected? Or someone else's car.

This we verify by checking the VIN in the frame (frame number check).

https://shkspr.mobi/blog/2018/06/how-i-became-leonardo-da-vi...

Had an interview for a company like that once, where they required that no work-related communication happen outside of their chat client. And they had cameras to check for that. The turnaround rate was through the roof.

I genuinely hope that you'll try and solve these problems using other methods. Building these systems just makes your employee's lives hell.

We don't do any of what you describe. When I said "continuous video", I was referring to the transporter taking a video of the state of the car — two minutes max. No livestream or tracking or anything.

I don't watch or control my employees or the transporters (they are just a client of a client). I don't even see the pictures they take before transport, usually just our customer.

It feels like you're wilfully misunderstanding something.

> isn't whoever controls your code the "timestamping party"?

No (and sort of yes). The result of the timestamp is instantly verifiable against the timestamped data, meaning the results of the timestamp can be viewed on a public blockchain explorer or using an API that interfaces with the blockchain, without trusting our code. If another party doesn't trust our frontend code, they can build their own frontend logic that interfaces with the blockchain in the backend to independently verify results. If someone is using our app, they implicitly trust our code, yes, but they don't have to trust our database. That's the difference.

> In both scenarios, you have no proof of when the photo was taken. It could've been two hours or ten minutes ago. There is no way to digitally verify it.

This is a solvable-ish problem. What our app does is require the photos to be taken in-browser, and adds a small stamp to the photo before hashing it with the most recent Bitcoin block hash. This way, we have a window of ~10 minutes within which we know the photo was taken.

Can this be abused? Yes. But the transporter is exceedingly unlikely to know how, and they also don't have access to the cars before handoff, so the concern is really negligible. Faking the photos is now at least a few order of magnitudes harder than before. We can improve on this in the future.

> posting a photo of a different vehicle

We ask the transporters to take a photo of the VIN in the frame, along with other photos (body, odometer, etc.). This is a pretty foolproof solution.

I think you misinterpreted the attack I was describing.

Let's say you rewrite your front-end code to change the timestamp. Sure, someone could read it, but reading source code every time it's updated is not a sustainable security practice. It's also especially easy to hide malicious code in JavaScript.

How does blockchain prevent that attack? Your blockchain is memorializing data that you have interfered with. Someone can definitely verify that whatever photo is on the blockchain was really added to it at whatever timestamp. But how does that give them any proof that the photo was actually taken at that timestamp?

All the blockchain does is say, "At [timestamp], this photo was added to the blockchain." It doesn't offer proof of who took it, where it was taken, what the subject was, or (crucically) when it was actually taken.

And that basic guarantee (that the photo was taken at a certain timestamp) is just as easy to accomplish with an append-only database.

Regardless, this is all about mitigating an extremely unlikely attack: your own company. Why do your own clients need to verify that you are trustworthy?

> What our app does is require the photos to be taken in-browser

> We ask the transporters to take a photo of the VIN in the frame, along with other photos (body, odometer, etc.).

I agree that these measures likely stop close to 100% of attempts to defraud you, especially because there is a chain of custody that makes fraud more difficult.

But I still don't see any reason this couldn't/shouldn't have just been built on a vanilla RDBMS. Hell, if you want to verify the timestamp, you could just instantly email the photo to someone via Gmail, since you can't fudge Gmail's SMTP timestamps.

As I said before, using blockchain here decentralizing trust in a situation where the source of truth is... you. And it still doesn't make you trustworthy, since you can alter the photos before ever hashing them.

I have a friend with a similar use case. His company solves it by taking Polaroids, and both parties sign the backs.

An app can always show the users fake results, regardless of what's genuinely stored in the distributed ledger.

Certificate Transparency gets the same guarantees as well, without using a blockchain.

The biggest hiccup with this proposal is that whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions. This is not the case on a public blockchain. With the solution you describe, we would basically be running our own psuedo-private blockchain, with no advantages over a private blockchain like IBM Hyperledger.

But we use a public blockchain for a reason.

Because Git is a Merkle DAG and blockchain is a Merkle chain. (I think that's the word)

So, although it would be ugly, you could store data in Git as a linear series of commits and get the same public or private ledger.

> whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions

But if your clients who don't trust you are monitoring the repo, and you do something like a `push --force`, they would see the hashes change.

> But we use a public blockchain for a reason.

I've tried to guess the reasons:

1. If the public ledger is watched by 100 other people, it's much harder to roll back an event than if it's only watched by a few clients who might not notice if you post an event and then immediately revoke it.

2. Since the public ledger gets a lot more traffic, its clock is more accurate. With a private ledger (Like the Git hack) you could still use the latest Bitcoin hash to prove "Commit B is made after Time A", but the window for "Commit B is made before Time C" is very large.

Honestly, my problem with blockchain is just the word "blockchain". I love public notarized ledgers. But I don't want to buy something that's riding off the hype of Bitcoin and buzzwords, and I don't want to sell that to people.

I need an audit log for something at work and I'm trying to figure out if this is useful. If it is, I would never tell my boss that someone called it blockchain. Non-programmers will think it's unbreakable Hollywood magic crypto.

As CT shows, there are other ways to solve the audit-logging-for-untrusted-parties problem.

How about we start calling real use cases PNL (Public Notarized Ledger) use cases? I love that term.

I'm also thinking, how do they trust my server?

With photographs it makes sense - A server that can tamper with photos live is not sci-fi, but it's also just a little bit expensive.

In my case I want to notarize text. What if I store "evil message" in my database and publish "good message" to the PNL?

Unless the end recipient of "evil message" is also logging to the PNL, (Which is hard, they're supposed to be a dumb client) nobody will ever contradict the server. I could round-trip the messages through the PNL. Make the recipient pull them from there instead of the server. But that sounds like extra risk.

It's a tricky problem, and in the end I'll have to cut lots of corners for convenience. That makes me sad.

RE: Timestamping text, check out https://app.assembl.net and open "Chronos". It should be self-explanatory to create a timestamp.

I think it's often used as a joke for how broad the definition of "a chain of blocks" is. Probably some people take the comparison too literally. Unless we manage to convince everyone and their moms that when EvilCorp pushed TheirCoin as "blockchain tech" (when really EvilCorp is the party controlling it) we should just laugh and call it EvilCorp Credits, which (last time an evilcorp tried that) we didn't, we need a more specific term than blockchain to distinguish EvilCorp Credits from Bitcoin.

And you think the actual implementation of the blockchain will be more secure and tamper pro of?

>And you think the actual implementation of the blockchain will be more secure and tamper pro of?

Yes, absolutely. Again XRPL as example because I know it best. There has never been a single byte tampered with in the last 8 years and its several TB of Tx data by now.

Edit: synchronising clocks is one of the hard problems in distributed computing https://en.wikipedia.org/wiki/Clock_synchronization

The Bitcoin block hash cannot be known before it's calculated, and a new one is calculated every 10 minutes. Works great.

It's complex to synchronize clocks perfectly, but to within a few seconds is easy and there aren't many cars that could rack up an appreciable mileage in such a short time.

But where this seems to fall apart is if you need very precise ordering (think stock trades), as an unpermissioned chain won't going you a high enough block rate. So you move to a trusted node that mints blocks, and at this point you might as well call it a ledger computer, issuing signed receipts.

The big unsolved problem is the analogue gap though, and how to get something from the real world into the chain - the person or device making the observation inherently need to become trusted oracles. In the odometer example, you could surely take a photo of the odometer before the joy ride, then submit the old picture once the vehicle is leaving your custody? Client side restrictions this is a live photo don't help as they can't be verified on-chain, so now the next person gets blamed? Or have I missed something here?

That there is an immutable log of the events is an implementation detail and could be solved with a write only DB completely independent of blockchain.

A public DTL has a public state unlike a normal DB everyone knows the complete DB and its distributed. If you write to it you can read form anyone else including your own node to verify it has in fact been written. Instead of trusting who is in control of the read only DB you trust that a no majority of nodes collude to tamper. Its important to know that there is a negative incentive to collude because almost all participant are participant in such a system because they theme self want to use an immutable ledger.

This does not apply to BTC or similar blockchains where the people (miners) in "control" (collectively) are not the primary users of the immutable ledger. Because there is a false incentive (money/block reward) to participate even if you have no interest in using the system at all.

AFAICT, this is not such a problem where a third party cannot be trusted (the only incentive would be if they contacted you and tried to bribe the modification, which doesn't seem worth it).

Otherwise, if the DBA can be trusted, it's not clear to me that the blockchain offers any additional verification, encryption, audit-ability, etc -- and it doesn't seem to me that the "DBA cannot be trusted" is a sufficiently possible risk scenario to try to eliminate from the equation

The global, open database provided by a blockchain solves this problem, and also allows anybody to read the state without relying on our company to maintain the database or for uptime.

In the aforementioned case, the pickup time in known, so all that matters is that the photos are timestamped before or at pickup time. We don't worry about 51% attacks because we use the Stellar blockchain, also used by Franklin Templeton investments and IBM and Keybase... The chance of a 51% attack going unnoticed is virtually zero.

The ledger is public, and anyone can view the history of the ledger using Stellar's API (a hosted version is available at https://horizon.stellar.org) or a blockchain explorer like https://stellar.expert.

The great thing is that the data is stored on a distributed series of nodes, so no syncing is needed.

But how are the many other people in the auto supply chain supposed to know that? With this solution, they don't have to trust our company, just the SHA256 hashing algorithm.

Math is easier to trust than a small startup.

Edit: To clarify, many of the people checking against the blockchain record are not our clients.

If the issue is that people are taking cars for joyrides why not just have the car post a route file to a database or to its own computers of all the trips. Are auto suppliers really taking joyrides AND hacking into the computers? If you are capable enough to do that wouldn't it also stand to reason you'd be capable enough to disable any tracking units?

I'd also argue that the "person who owns the database" is not just trusted but also trustworthy. They have an incentive to keep lies out of the data.

If the people you can't trust are your users, then blockchain doesn't really add anything. They can insert lies, and you have to verify them. All you get is a guarantee that no one changed their lies to something else.

The blockchain adds nothing useful to the setup, you could have the exact same level of confidence if each link in the chain e-mailed a photo to a central inbox.

You just described a blockchain. Why rebuild what already exists? A blockchain is a great drop-in solution and reduces our costs and implementation worries massively. And the distribution of this public blockchain is much more decentralized than we could ever achieve running our own nodes.

I purposefully did not describe a blockchain, although that depends on what your definition of blockchain is.

If we're defining blockchain as something descending from Satoshi's 2008 paper, then what I described is not a blockchain.

The distinction I'm making is one of trust. I was describing a database with centralized trust.

> Why rebuild what already exists? A blockchain is a great drop-in solution and reduces our costs and implementation worries massively.

I didn't say you should rebuild anything.

It sounds like you think that the only easy-to-use, mature append-only databases with cryptographically verifiable logs (popularly called "ledger databases" these days) are blockchains. That's not true. All the major clouds have such databases now.

> And the distribution of this public blockchain is much more decentralized than we could ever achieve running our own nodes.

I still don't see any evidence (either from you or anyone else advocating blockchains) that this is good for you use case.

Can you please explain an attack that is possible against something like Amazon's QLDB[1] but is impossible against a public blockchain?

There's also the issue of speed and usage costs of public blockchains, not to mention the frequent bugs, 51% attacks, and other uncertainties that come up.

We know the costs of building on public blockchains. I'm dying for someone to come up with a benefit that is only possible on that blockchain. Every time they try, it seems to be benefits that are shared with services like QLDB or a variety of FOSS solutions.

1. https://docs.aws.amazon.com/qldb/latest/developerguide/verif...

People made insane money with Bitcoin, Ethereum and others. People then dropped lots of other "coins" that eventually no one cared about. "Blockchain as useful technology" is the story to sell the next "coin". Employing a couple of devs and funding a few blockchain startups is trivial money in this context, often sponsored by "believers" (who got rich in the early days)

Blockchain tech comes with inescapable complexities and problems: bugs and security issues can't be fixed in blockchain programs. Any trivial action on the blockchain requires mining, i.e. the very thing that's done with specialized hardware in areas where energy is cheap.

My last point seems to be tangential, but do try it yourself with a small project on a private Ethereum chain, using geth, web3.js, there are good tutorials out there. Usually when you try out a fancy new tech you "get it" after a while, but I definitively did NOT see any way this is feasible.

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.

The owner could be required to send back a confirmation.

But I agree, a trusted hash/timestamp service might provide better usability.

I've been trying to analyze the robustness of their approach but I think their hashing algorithm (sha of json content blob) and the trustworthiness of the blockchain (they use EOS) are the two only components. Can someone who has more background in cryptography and blockchains perhaps share some thoughts about their approach?

Congrats to the team for their EU grant and traction, but this feels to me like a "problem looking for a solution". Take this with a grain of salt, as we are somewhat adjacent competitors.

Edit: apparently I don't know how to read. (Asked what parent post was working on)

Blockchain is not a "killer" feature of the app, but it's another layer of security. Databases are the core, but staff with access can edit a database in seconds. Maybe one way to think of it is like cash registers. The person operating a cash register can still steal it, but it's a lot harder than if it were just a box. It won't stop a dedicated person, but will greatly discourage doing it casually.

A lot of people talk about the benefits of blockchain and then describe a cryptographically-secured, append-only database (something like Amazon's QLDB[1], which does not have distributed trust or ownership).

If you're not actually using a blockchain, then disregard.

If you are using a blockchain, how does it add trust? Isn't your company, which controls the I/O for the system, still the central authority?

1. https://aws.amazon.com/qldb/features/