Hacker News Reader

Comment by sebmellen | Hacker News Reader

The biggest use case I have found of blockchain tech is timestamping, especially in a case where the timestamping party cannot be trusted to act honestly because of conflicting interests.

I'll give you an example, from one of my startup's enterprise customers. This company needs to ensure that their high-end auto inventory remains in the same state through transport — the mileage, the car body, etc. They've had issues with transporters taking these high-end cars for joyrides, and it's hard to detect when this happens.

Our solution lets the transporter timestamp the odometer reading and car body with photos at time of pickup, on a blockchain. When the car is dropped off, it's just a matter of comparing the blockchain record with the car's actual state. Our system lets many parties who don't know or trust each other view the same "shared state" on a public blockchain ledger (Stellar), enforcing between these parties.

We provide a similar service for researchers who want to prove they were the first ones to make a discovery. You can read more about that at https://assembl.net.

Edit: You can try our timestamping app (still in beta so excuse some kinks) online at https://app.assembl.net. I would love to hear your thoughts!

View on HN

Sorry, but your solution solves nothing. The transporter could take a picture of the odometer and tweak the image. Your solution is only as secure as the input flow and you can't control it. A blockchain can't reflect physical reality. It can only reflect what someone said/says physical reality is. Additionally, they have to trust you to push the "right" data to the blockchain. If they are already trusting you, you can just run the database yourself.

I would just like to say that if anyone has a rational counterargument to this, I really want to hear it. This is precisely the observation past which the logic becomes less coherent in just about any conversation I've had on blockchain applications.

Maybe instead of an image, both parties could use an ODB reader that signs the mileage cryptographically, and pushes it to the blockchain?

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.

Why can't you just sign the image of the odometer?

Well 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.

It would be cool to have technology that tells you how long is a trip, oh wait, precise maps are hundreds of years old.

Please see my comment in response to the grandparent comment. I think it will address your concerns with a rational counterargument.

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!

I think the thing that you have to answer is why you need distributed consensus. You're a startup with a business relationship with your customers -- you're the common trusted party. Your customers are using your software so if they were worried about you cheating the system they (and you) have bigger problems since your business is reputation.

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.

You're right about everything but that we're the common trusted party. We have a relationship with the receiver. They want to be sure nothing happens in transit from origin. We do not have a business relationship with the transporters (many of whom are independent).

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.

I don't want to malign the transporters in your business, but the chance that they actually meaningfully understand the nuance of this is slim to none.

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.

> Either people trust you, or they don't.

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.

The ROM on most modern ECUs is cryptographicly protected isn't it? (I know it is on my 2006 Toyota Carola because I've looked at replacing it.)

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.

The solution solves the exact issue. A claim of fact is sent from one party to another and the blockchain--which is independent of either party's trust--holds that claim including who it was sent from, when, and what the claim was. The only thing it has the potential to not solve is the possibility of the party lying in that claim.

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.

Gmail would be just as good. Have them send you an email as part of the handoff process. Time/date/photo will be documented in a source of Truth

"Doctors hate him..."

If you know anything about email headers, this is a bad solution. Are you suggesting that everyone has a shared Gmail account with one password? What happens when an email gets deleted?

What are you talking about? The suggestion was that the transporter simply send an email with the same data. The receiving party would get the email, and when an email is sent the sending party has no access to change it.

Yes, in that case the receiver and all other custodians in the party would need shared access to the same Gmail account, or many emails would be sent to the ever expanding list of custodians, leaving a nightmare of 1000+ email long chains of unsearchable information. It's not a feasible solution.

I suppose email is searchable, especially if it includes an order ID.

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

No need to be so snarky.

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.

I agree with the question: is anything really be solved here? No, not really. A db table of jpegs taken at different points in the hand off is essentially fine too. Carfax seems to so fine without blockchain. And really the bottom line is the end recipient: what recourse is there if the car shows up with too many miles?

The recourse is that the transporter doesn't get paid. Just a small adjustment to incentives massively changes the occurrence of damage to the car or anything similar.

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?

If you are the trusted party and your servers are secure, why do you need a blockchain?

We are not the trusted party. I have tried to make this abundantly clear in my other comments.

I think if saying that it’s a simpler, easier solution that provides the guarantees that you need, and the other poster still does not understand this, it’s safe to say you shouldn’t put more effort into this. Thanks for your explanations :)

Why can't you be the trusted party? At the end of the day, one of your servers is involved in the blockchain and using server capacity to do that. Why can't you just use that server capacity to host a simple app where people send the images?

> Build a system like this yourself and we'll talk about it then.

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.

It makes it hard to alter historical data. It does not prove the data was correct to begin with. Blockchain isn't the only way to do this but it is a good way if you don't trust the parties holding the data not to attempt to alter it. You could avoid that by holding your own copy of the data and checking against that. What solution is best depends on the situation.

actually, the manipulation you mention isn't possible. the image would be 'hashed' when included on the blockchain signature, and it's computationally impossible to edit the image AND produce the same hash AND those changes being what you actually want the forgery to reflect. (producing the same haash is impossible enough)

> where the timestamping party cannot be trusted to act honestly because of conflicting interests

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.)

The picture of the car is not protected by hard crypto until it's inserted into the blockchain. Until it is inserted the trust chain breaks at the questions of:

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

Blockchain works for currencies, since currencies are just numbers in a ledger. And numbers can be easily secured with strong crypto.

"Secured by hard crypto" is item fifteen on someone's priority list after usability, cost, reliability, speed and the font used on the marketing page. Note that none of the questions you raise are answered by protecting a jpeg with hard crypto... (If that was the point, my apologies for re-explaining it).

It was, but thanks for clarifying. :)

See my response to the grandparent comment for more details.

> 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).

Your company sounds pretty awful to work for, where suggestions like, "Watch the employees at all times" are apparently taken seriously.

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.

They're only making their clients employees lives hell.

What?

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.

The only possible explanation to your comment is that you replied to the wrong thread.

I couldn't find this link originally, but this is effectively what I'm talking about.

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

To address your concerns:

> 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.

> 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.

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.

What if I write a browser extension that lets me upload a file from my computer with an arbitrary timestamp when I'm prompted to take a photograph? That seems like the obvious attack.

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

It seems like this is a case where the customers would effectively be trusting that your app does what it claims it does, in which case the detail that blockchain is used probably doesn't matter that much.

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

A GitHub repository would provide the same level of guarantees right? Everyone else gets read access - the transporter gets write access. They can't rewrite history, or else it gets caught on a mirror that anyone else is maintaining.

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

No... I'm not sure where people get the idea that Git provides what a blockchain does.

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.

> I'm not sure where people get the idea that Git provides what a blockchain does.

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.

> the idea that Git provides what a blockchain does.

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.

I agree with you on the word blockchain. I hate it. I hate the crypto associations too.

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

Sure.

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.

I have to be honest — I don't really understand what you're trying to say.

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

As an addendum to the idea, perhaps have the git commits signed via a public timestamping server. (ie to say, any commits that do not have a corresponding timestamped signature will not be accepted).

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

If you ignore the fact that people at GitHub can delete whatever they want. The difference is that they probably wont tamper with someones data but they can. On a distributed ledger however "they" are many different humans who don't know each other and have only one common interest and that is that no one tampers with the data. And even if a majority would collude and tamper it would be impossible to hide that from the others.

Well, considering the business is transporting sports cars, what's the threat model here? Someone wants to take the car on a 15min joyride and will bribe a Github employee to be able to do that?

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

I didn't meant to say that this is a legit reason to use a DL instead of Github/a database. I just wanted to point out the difference. It may or may not matter in this case because the thread is very limited. There are still very valid reasons to use a DL for example the XRPL had a uptime of 100% in the last year. GitHub certainly does not have that. Also using a public DL means zero maintenance. Again I use the XRPL as example it runs stable and public since over 8 years. To use it you need nothing but an address of a node or better a few for backup because a single nodes obviously can have downtime. No server, no domain register, no cloud computing provider, no backup plans, nothing. The only thing you pay is the Tx "fee" which is only there to prevent spam Tx. Its like 0.00001 XRP so thousands of transactions will cost you cents at most.

>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.

How do you trust the source of the timestamp used for the pictures? I am assuming the clock on the camera is not synchronised with all nodes participating in the blockchain. May be I misunderstood the application.

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

It also reminds of this paper I read which uses blockchains to capture the video frames from car dash cam for insurance purposes. I wondered about the same clock synchronisation issue https://ieeexplore.ieee.org/abstract/document/8752067

Presumably each car handover is conducted with an internet-connected cellphone, making it trivial to get a trusted timestamp accurate to a second or two.

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.

You need some trusted source of time to make this work. So it won’t be completely trust less system.

The trusted source of time is the Stellar blockchain, and the last Bitcoin block hash, giving us a ~10 minute period wherein the photo must have been taken. Essentially, we abstract the time synchronization issue away from the photo taker to an external trusted source.

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

Noting some of the sibling comments about timestamping and trust, something I've thought about before when explaining use of Blockchain is that the real use case is verifying the relative order and integrity of events. Clearly the time granularity within which you get relative order assurance will be dictated by the order interval.

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?

To make sure I understand it correctly, the blockchain is acting as a distributed notary service, right? That definitely feels useful.

The power of a notary is that someone is legally verifying the state of the document under penalty of perjury. In this case, you don't trust the party doing the verification, by definition, and there's no second party, so I don't see what this solves.

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.

Agree. There are consequences if the notary lies. If bad data is posted to the blockchain ... Well ... So what? That's why I asked the original poster of scenario what the end receiver's recourse is if he gets a car with too many miles? Arguing about blockchain and what it did or was supposed to do will be immaterial by then.

As I responded to you in another comment, the recourse is that the transporter is not paid. This is laid out in a legal contract which references the timestamping system.

There is no such thing as a "write only DB" Who ever has control over that DB physically can tamper it. From external such a DB would be a black box. You store something and read again to check if it has been stored but whoever is in controller can just drop it after wards anyway. You have no clue whats actually happening. The black box could contain 2 DBs you query one and everyone else queries another.

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.

It is my understanding that the only functional difference between a database, and a blockchain, is the elimination of a trusted third party who would have to administer the database (and could, maliciously, alter that DB)

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

why does it need a distributed blockchain though? Why not just put it in a database?

Because many companies with many conflicting interests need to be able to trust each other. If we put this data in a database, our enterprise customer can tweak the system to their advantage if they make a deal with us.

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.

So the customer set up an IT service with multiple servers to sync with yours so that both can sync to the ledger? How does that work in practice? Is someone also monitoring that nobody is doing a 50% attack? Are both parties present when something is inserted into the blockchain?

Hmm, I'm not quite sure what you're trying to ask.

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.

In some examples I've seen non-public ledgers, with X nodes run by the same company. And then they claim "we use blockchain so we're tamper-proof!"

Is your organization unusually susceptible to that kind of corruption? It seems like blockchain or no, the clients have to trust that you'll provide the service you agreed to and not cash their checks and disappear etc.

No.

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.

Because the person who owns the database has to be trusted, where here no one has to be

This is not true. You are always trusting someone. <-- that is a really really big period. In this case you are trusting the authors of the code which this process runs on. The machines that this code runs on. And last but not least the fact that no one has control over majority of the nodes. You are always trusting someone or something.

In GP's example, the "person who owns the database" is already trusted because they wrote the software. The software can insert lies into the blockchain very easily.

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.

Call me cynical but I'm still confused by this.

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?

That sounds ridiculously impractical, and far more technologically complex and time-consuming than the solution we've built. You're free to compete with us though — I'd be interested to see how you manage the route files, how you make sure that the database is neutrally controlled, how you use the car computer to determine whether or not there's a dent in the car body...

What does the blockchain add to the equation beyond what the photo already does?

The timestamp of the photo. This way we know that the photos were taken before transport, and the state of the car when it's dropped off should match the state of the car at pickup.

Wouldn't sending a copy of the photo to the owner prior to transportation be sufficient? Actually, why doesn't the owner take a picture himself? After all I could easily manipulate the picture before timestamping.

> 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.

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

The owner could be required to send back a confirmation.

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

Nothing proves that the timestamp accurately reflects when the photo was taken or that the photo itself is even accurate. If I wanted to joy-ride one of these cars I'd simply do so before taking the photo. The odometer display can also be trivially modified for the sake of a photo (i.e. roll back the odo for a photo and then revert to accurate numbers after the photo)

This has been the only comment I'm actually interested in seeing a response from parent commenter on.

There is no solution for the oracle problem: someone has to input the truth, and that entity can just run a database. End of story.

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.

How do you undo any dents that may occur during a joyride though?

I'm not sure what you're asking. If the possibility of dents were enough to prevent joyrides then the entire conversation would be moot, blockchain or otherwise.

The next entity in the supply chain would have an odometer that didn't match the picture that was previously posted. It limits who is possibly at fault to a minimum of one of two parties, which I'm sure could be narrowed down further by corroborating evidence. It highly discourages it because at the very least, you would be the first suspect with no real finger to point.

That's true, but none of that is enabled by blockchain. You can do all of that with an append-only, distributed database that is cryptographically verifiable. You don't need a public blockchain (or any blockchain at all).

> an append-only, distributed database that is cryptographically verifiable

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.

> You just described a blockchain.

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...

> It limits who is possibly at fault to a minimum of one of two parties

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.

Presumably, the first person who hands off the car (in a “known good” state) would also insert a photo of the odometer into the blockchain.

A cool initiative that applies time-stamping on blockchain to fight fake news/increase accountability in online publishing is https://wordproof.com/.

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?

I find Wordproof interesting. Their technology is fine as blockchain tech goes, but I don't see how timestamping fights fake news.

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.

Thanks for sharing your opinion.

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

Timestamping existed long before blockchains. You can just push the image to github, there is no way to change the push timestamp.

We do something similar at our startup. Basically we're a communication tool for construction, maintenance work and visitor management. Our selling point is simply data consistency, e.g. you can't edit posts, unlike on Facebook, and deleting will give a notice. Photos taken from the app are signed and location stamped. I think it's interesting that people comment you can just take a photo of an odometer, but that's not something that two parties do all the time; it's best to just automate that process.

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.

I'm curious what you mean by "blockchain" here.

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/

How do you authenticate that timestamps are accurate?

A company called GuardTime has implemented this in production way before the BC craze hit.

Reply on news.ycombinator.com