3 ms·

With a blockchain the end user could tag the part hash as being installed and you could see exactly who each supplier had the part at what time. A database coul

With a blockchain the end user could tag the part hash as being installed and you could see exactly who each supplier had the part at what time. A database could go offline and stop a part from begin installed into a jetliner but a blockchain would be always available. The manufacturer could track which parts the end user has in stock and installed and make production decisions easier. A consortium of manufacturers could use the same blockchain for all their parts. I am not claiming it's more efficient for all use cases just that there are some distributed trust applications that seem to make sense.

eridius 9y ago
The only interesting part here is the behavior when the manufacturer's API goes down, and that's solveable just by having the clients maintain a queue of their failed modifications and retry them later when the API goes back up again. And of course the manufacturer can even provide the software that does this to the client so the client doesn't have to do any work for it.
- twic 9y ago
  This little subthread is a great example of a kind of fallacy that seems endemic amongst blockchain believers. "A blockchain solution X can solve problem P, therefore blockchain is useful". Without asking if there is a non-blockchain solution Y that can also solve P, and if so, what the relative merits of X and Y are. Given that a blockchain is just a distributed database with a distributed certification mechanism, you can generally immediately construct a couple of non-blockchain solutions by first removing distributed certification, then distribution of the database itself. You can then quickly see the eigenmerits of those kinds of distribution for the problem at hand. I have yet to see an example where they are positive.
- vsssk 9y ago
  Wait, so, if I used blockchain I wouldn't have to maintain a queue of.. failed modifications and retry them later when the API goes back up again. neither would I have to provide the software that does this to the client so the client doesn't have to do any work for it. You're literally describing a benefit of blockchain. Its right under your nose.
  - icebraining 9y ago
    maintain a queue of.. failed modifications and retry them later when the API goes back up again. Your blockchain client still has to have a queue of transactions to be submitted, as the Internet is not magically reliable. You're literally describing a benefit of blockchain. Its right under your nose. It is a benefit of the blockchain, in the same way that transporting people is a benefit of a dump truck. That doesn't mean it's appropriate for that job. There are many, many tools for storing and pushing messages to remote servers. The blockchain clients can do it, but it's absurd to use them unless you need the rest of the blockchain stuff. Even an email server (MTA) would be a better option.
- langitbiru 9y ago
  The blockchain solution can gives more benefits more than "when the manufacturer's API goes down". So there are 3 actors in supply chain: manufacturers, retailers, and consumers. In your solution (centralized database and API), you rely on the goodwill of the manufacturers which is fine (I guess) in most cases. But retailers and consumers have good reason sometimes not to trust the manufacturers. Vice versa. Okay, let's consider this case: the manufacturer produces milk packaged in a bottle. So they put QR code in the milk, and put some information in their database. Let's say they put the production date into this database. QR code: Abbbccc Information: produced on January 5th 2018 They send the milk to the warehouse A. Warehouse A keeps the milk for a night before sending to the retailers. But alas, there is a storm preventing the warehouse sending the milk to the retailers. So 1 week later, it delivers the milk to the retailers. Warehouse A informs the manufacturer about the incident. But let's say this milk only has 10 days before it hits expiry date after the production. Manufacturer decides to lie to the retailers. They updates the database. QR code: Abbbccc Information: produced on January 11th 2018 In blockchain, this corruption can be prevented.
  - icebraining 9y ago
    The blockchain is not what prevented that; the manufacturer publicly publishing that information is what prevented that. The fact that they did so to a blockchain is irrelevant. Say the manufacturer instead just has an RSS feed on their site, where they publish that information (digitally signed, of course) as the milk is produced. The retailers just have to keep a local copy of that feed, and so they can detect any later tampering.
    - eridius 9y ago
      And if you really love the blockchain, you can always run your own blockchain that simply records snapshots of the manufacturer's RSS feed! </sarcasm> That said, this does bring to mind one genuinely useful aspect to the blockchain I forgot about, and that's the fact that Keybase uses the bitcoin blockchain (IIRC) to periodically record the Merkle tree roots that they use to verify their own information. The only reason to do this is as proof that they're not tampering with the Keybase history that they publish, and so fundamentally this is just the same thing as digital notarizing that I did mention before (except in this case it doesn't matter whether the courts recognize it as being valid). And you could still accomplish this without a blockchain simply by having a neutral third party agree to keep a record of the merkle tree roots, but this is one of the few cases where the 'trustless' aspect of the blockchain actually is useful. Though of course even with a 'trustless' blockchain you still have to trust the chain itself. With Bitcoin, you can assume nobody's managed to execute a 51% attack against the chain (at least, for the time being; AIUI with the way things are going it looks like the Chinese government might be able to do it by exerting pressure on all the Chinese miners), but if you're running your own chain, how do you make mining the chain popular enough to prevent attacks? In fact, to my mind, the only real benefit of Bitcoin at this point is the fact that it's so popular it's hard to attack (well, except by the Chinese government).

eridius 9y ago

The only interesting part here is the behavior when the manufacturer's API goes down, and that's solveable just by having the clients maintain a queue of their failed modifications and retry them later when the API goes back up again. And of course the manufacturer can even provide the software that does this to the client so the client doesn't have to do any work for it.

twic 9y ago
This little subthread is a great example of a kind of fallacy that seems endemic amongst blockchain believers. "A blockchain solution X can solve problem P, therefore blockchain is useful". Without asking if there is a non-blockchain solution Y that can also solve P, and if so, what the relative merits of X and Y are. Given that a blockchain is just a distributed database with a distributed certification mechanism, you can generally immediately construct a couple of non-blockchain solutions by first removing distributed certification, then distribution of the database itself. You can then quickly see the eigenmerits of those kinds of distribution for the problem at hand. I have yet to see an example where they are positive.
vsssk 9y ago
Wait, so, if I used blockchain I wouldn't have to maintain a queue of.. failed modifications and retry them later when the API goes back up again. neither would I have to provide the software that does this to the client so the client doesn't have to do any work for it. You're literally describing a benefit of blockchain. Its right under your nose.
- icebraining 9y ago
  maintain a queue of.. failed modifications and retry them later when the API goes back up again. Your blockchain client still has to have a queue of transactions to be submitted, as the Internet is not magically reliable. You're literally describing a benefit of blockchain. Its right under your nose. It is a benefit of the blockchain, in the same way that transporting people is a benefit of a dump truck. That doesn't mean it's appropriate for that job. There are many, many tools for storing and pushing messages to remote servers. The blockchain clients can do it, but it's absurd to use them unless you need the rest of the blockchain stuff. Even an email server (MTA) would be a better option.
langitbiru 9y ago
The blockchain solution can gives more benefits more than "when the manufacturer's API goes down". So there are 3 actors in supply chain: manufacturers, retailers, and consumers. In your solution (centralized database and API), you rely on the goodwill of the manufacturers which is fine (I guess) in most cases. But retailers and consumers have good reason sometimes not to trust the manufacturers. Vice versa. Okay, let's consider this case: the manufacturer produces milk packaged in a bottle. So they put QR code in the milk, and put some information in their database. Let's say they put the production date into this database. QR code: Abbbccc Information: produced on January 5th 2018 They send the milk to the warehouse A. Warehouse A keeps the milk for a night before sending to the retailers. But alas, there is a storm preventing the warehouse sending the milk to the retailers. So 1 week later, it delivers the milk to the retailers. Warehouse A informs the manufacturer about the incident. But let's say this milk only has 10 days before it hits expiry date after the production. Manufacturer decides to lie to the retailers. They updates the database. QR code: Abbbccc Information: produced on January 11th 2018 In blockchain, this corruption can be prevented.
- icebraining 9y ago
  The blockchain is not what prevented that; the manufacturer publicly publishing that information is what prevented that. The fact that they did so to a blockchain is irrelevant. Say the manufacturer instead just has an RSS feed on their site, where they publish that information (digitally signed, of course) as the milk is produced. The retailers just have to keep a local copy of that feed, and so they can detect any later tampering.
  - eridius 9y ago
    And if you really love the blockchain, you can always run your own blockchain that simply records snapshots of the manufacturer's RSS feed! </sarcasm> That said, this does bring to mind one genuinely useful aspect to the blockchain I forgot about, and that's the fact that Keybase uses the bitcoin blockchain (IIRC) to periodically record the Merkle tree roots that they use to verify their own information. The only reason to do this is as proof that they're not tampering with the Keybase history that they publish, and so fundamentally this is just the same thing as digital notarizing that I did mention before (except in this case it doesn't matter whether the courts recognize it as being valid). And you could still accomplish this without a blockchain simply by having a neutral third party agree to keep a record of the merkle tree roots, but this is one of the few cases where the 'trustless' aspect of the blockchain actually is useful. Though of course even with a 'trustless' blockchain you still have to trust the chain itself. With Bitcoin, you can assume nobody's managed to execute a 51% attack against the chain (at least, for the time being; AIUI with the way things are going it looks like the Chinese government might be able to do it by exerting pressure on all the Chinese miners), but if you're running your own chain, how do you make mining the chain popular enough to prevent attacks? In fact, to my mind, the only real benefit of Bitcoin at this point is the fact that it's so popular it's hard to attack (well, except by the Chinese government).