9 ms·

What would you suggest as an alternative where each step still independently verifies all previous steps? I guess you could just store it in a database and sto

What would you suggest as an alternative where each step still independently verifies all previous steps? I guess you could just store it in a database and store the hashes and signatures as columns but again, that seems more like implementing a blockchain strategy using a traditional RDBMS. *After your edit: It seems like the blockchain is still useful in this case as a series of signed statements where it can be (generally) verified that each signature was made by a certain entity at a certain point in the chain.

bunderbunder 8y ago
I'm not a logistics guy, so maybe I'm missing something here, but I think I'd just not do it at all. Why would I need to do such a thing? What, in practical terms, does it get me?
- pythonaut_16 8y ago
  So looking back at your post, I think the big difference is trusting someone's key isn't equivalent to trusting them. Trusting Alice's key just means I can trust that a statement signed by Alice's key was indeed signed/made by Alice. The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block. One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob). So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key. I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.
  - deleted 8y ago
    [deleted]
  - bunderbunder 8y ago
    So I think that, here, the 2nd-to-last question bubble in the flow chart is the key one. Because the question you're circling around is, "How do we verify that records are written by specific people?" If you can centralize the records management, then you don't have a problem deciding who should own the record store. At that point, good old-fashioned authentication will solve your problem. If you can't centralize records management, then things get trickier. But I think the trickiest part would still be to come up with a non-contrived logistics scenario where there isn't an obvious custodian you can put in charge of a centralized record.
    - pythonaut_16 8y ago
      I was imagining a potentially offline scenario where the blocks are physically recorded (i.e printed) and attached to the package as some kind of barcode or QR code. I suppose you could also deal with a scenario where the digital record is primarily transported with the shipment as well. A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain. One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring. Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.

bunderbunder 8y ago

I'm not a logistics guy, so maybe I'm missing something here, but I think I'd just not do it at all. Why would I need to do such a thing? What, in practical terms, does it get me?

pythonaut_16 8y ago
So looking back at your post, I think the big difference is trusting someone's key isn't equivalent to trusting them. Trusting Alice's key just means I can trust that a statement signed by Alice's key was indeed signed/made by Alice. The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block. One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob). So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key. I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.
- deleted 8y ago
  [deleted]
- bunderbunder 8y ago
  So I think that, here, the 2nd-to-last question bubble in the flow chart is the key one. Because the question you're circling around is, "How do we verify that records are written by specific people?" If you can centralize the records management, then you don't have a problem deciding who should own the record store. At that point, good old-fashioned authentication will solve your problem. If you can't centralize records management, then things get trickier. But I think the trickiest part would still be to come up with a non-contrived logistics scenario where there isn't an obvious custodian you can put in charge of a centralized record.
  - pythonaut_16 8y ago
    I was imagining a potentially offline scenario where the blocks are physically recorded (i.e printed) and attached to the package as some kind of barcode or QR code. I suppose you could also deal with a scenario where the digital record is primarily transported with the shipment as well. A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain. One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring. Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.