10 ms·

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 becaus

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

xchaotic 6y ago
why does it need a distributed blockchain though? Why not just put it in a database?
- sebmellen 6y ago
  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.
  - dasudasu 6y ago
    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?
    - sebmellen 6y ago
      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 https://horizon.stellar.org) or a blockchain explorer like https://stellar.expert https://stellar.expert. The great thing is that the data is stored on a distributed series of nodes, so no syncing is needed.
      - laurensr 6y ago
        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!"
  - sfkdjf9j3j 6y ago
    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.
    - sebmellen 6y ago
      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.
- deleted 6y ago
  [deleted]
- jedimastert 6y ago
  Because the person who owns the database has to be trusted, where here no one has to be
  - blahblahblah20 6y ago
    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.
  - smt88 6y ago
    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.
- handmodel 6y ago
  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?
  - sebmellen 6y ago
    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...
captn3m0 6y ago
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.
- sebmellen 6y ago
  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.
  - lucb1e 6y ago
    > 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.
  - ReactiveJelly 6y ago
    > 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.
ricklamers 6y ago
A cool initiative that applies time-stamping on blockchain to fight fake news/increase accountability in online publishing is https://wordproof.com/ 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?
- sebmellen 6y ago
  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.
  - ricklamers 6y ago
    Thanks for sharing your opinion. Edit: apparently I don't know how to read. (Asked what parent post was working on)
root_axis 6y ago
What does the blockchain add to the equation beyond what the photo already does?
- sebmellen 6y ago
  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.
  - pintxo 6y ago
    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.
    - detaro 6y ago
      > 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.
      - pintxo 6y ago
        > 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.
  - root_axis 6y ago
    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)
ummonk 6y ago
To make sure I understand it correctly, the blockchain is acting as a distributed notary service, right? That definitely feels useful.
- _asummers 6y ago
  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.
  - doonesbury 6y ago
    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.
    - sebmellen 6y ago
      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.
  - noxer 6y ago
    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.
goatinaboat 6y ago
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. I have a friend with a similar use case. His company solves it by taking Polaroids, and both parties sign the backs.
vinni2 6y ago
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 https://en.wikipedia.org/wiki/Clock_synchronization
- vinni2 6y ago
  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 https://ieeexplore.ieee.org/abstract/document/8752067
- michaelt 6y ago
  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.
  - vinni2 6y ago
    You need some trusted source of time to make this work. So it won’t be completely trust less system.
- sebmellen 6y ago
  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.
smt88 6y ago
> 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.)
- bb88 6y ago
  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.
  - hirsin 6y ago
    "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).
    - bb88 6y ago
      It was, but thanks for clarifying. :)
nitwit005 6y ago
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.
snarf21 6y ago
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.
- rebelos 6y ago
  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.
  - beh9540 6y ago
    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.
    - FunkyMJ 6y ago
      Why can't you just sign the image of the odometer?
  - thekevan 6y ago
    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.
    - 6y ago
muzani 6y ago
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.
- smt88 6y ago
  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/ https://aws.amazon.com/qldb/features/
catlifeonmars 6y ago
How do you authenticate that timestamps are accurate?
g_p 6y ago
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?
setr 6y ago
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
andreskytt 6y ago
A company called GuardTime has implemented this in production way before the BC craze hit.
BMSmnqXAE4yfe1 6y ago
Timestamping existed long before blockchains. You can just push the image to github, there is no way to change the push timestamp.

xchaotic 6y ago

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

sebmellen 6y ago
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.
- dasudasu 6y ago
  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?
  - sebmellen 6y ago
    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 https://horizon.stellar.org) or a blockchain explorer like https://stellar.expert https://stellar.expert. The great thing is that the data is stored on a distributed series of nodes, so no syncing is needed.
    - laurensr 6y ago
      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!"
- sfkdjf9j3j 6y ago
  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.
  - sebmellen 6y ago
    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.
deleted 6y ago
[deleted]
jedimastert 6y ago
Because the person who owns the database has to be trusted, where here no one has to be
- blahblahblah20 6y ago
  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.
- smt88 6y ago
  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.
handmodel 6y ago
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?
- sebmellen 6y ago
  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...

captn3m0 6y ago

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.

sebmellen 6y ago
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.
- lucb1e 6y ago
  > 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.
- ReactiveJelly 6y ago
  > 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.

ricklamers 6y ago

A cool initiative that applies time-stamping on blockchain to fight fake news/increase accountability in online publishing is https://wordproof.com/ 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?

sebmellen 6y ago
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.
- ricklamers 6y ago
  Thanks for sharing your opinion. Edit: apparently I don't know how to read. (Asked what parent post was working on)

root_axis 6y ago

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

sebmellen 6y ago
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.
- pintxo 6y ago
  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.
  - detaro 6y ago
    > 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.
    - pintxo 6y ago
      > 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.
- root_axis 6y ago
  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)

ummonk 6y ago

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

_asummers 6y ago
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.
- doonesbury 6y ago
  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.
  - sebmellen 6y ago
    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.
- noxer 6y ago
  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.

goatinaboat 6y ago

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. I have a friend with a similar use case. His company solves it by taking Polaroids, and both parties sign the backs.

vinni2 6y ago

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 https://en.wikipedia.org/wiki/Clock_synchronization

vinni2 6y ago
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 https://ieeexplore.ieee.org/abstract/document/8752067
michaelt 6y ago
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.
- vinni2 6y ago
  You need some trusted source of time to make this work. So it won’t be completely trust less system.
sebmellen 6y ago
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.

smt88 6y ago

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

bb88 6y ago
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.
- hirsin 6y ago
  "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).
  - bb88 6y ago
    It was, but thanks for clarifying. :)

nitwit005 6y ago

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.

snarf21 6y ago

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.

rebelos 6y ago
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.
- beh9540 6y ago
  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.
  - FunkyMJ 6y ago
    Why can't you just sign the image of the odometer?
- thekevan 6y ago
  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.
  - 6y ago

muzani 6y ago

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.

smt88 6y ago
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/ https://aws.amazon.com/qldb/features/

catlifeonmars 6y ago

How do you authenticate that timestamps are accurate?

g_p 6y ago

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?

setr 6y ago

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

andreskytt 6y ago

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

BMSmnqXAE4yfe1 6y ago

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