4 ms·

> I don't understand why even this is sensible. Why not just use a database? Who's gonna run it? Any individual company in the chain has a vested interest in

> I don't understand why even this is sensible. Why not just use a database? Who's gonna run it? Any individual company in the chain has a vested interest in fudging the data, and the technical means to do so. A private third-party lacks oversight (and thus could also be given a vested interest in fudging data). A government agency could do it (assuming one's government is trustworthy, which is often a poor assumption), but that would likely preclude international cooperation unless it's something like the UN running it (and even then). > The only miners/validators on a produce blockchain are likely to be agri-companies anyway. Preferably you'd use an existing public blockchain rather than spinning up an entirely new one. Even if there was such a blockchain solely for tracking produce, the fact that no individual agri-company has control over its data makes it more trustworthy/impartial than some centralized database.

acdha 4y ago
The problem is that blockchains cost more and add significant performance reliability problems without adding trust. You could solve this problem using PKI with orders of magnitude lower computational and storage cost, and that'd remove the requirement to have an always-on network service. However, that's still missing the point that this is fundamentally a problem about humans in the real world and the technology can't magically change that. The problems with supply chain authenticity aren't a question of record keeping but whether those records are accurate. If my inspector is being paid off, he'll do the same thing for the blockchain record that he was doing with paper. If things are being tampered with in shipping, the same people will do the same things and you'll have the same dodgy goods arriving at their destination except they'd now have valid but inaccurate blockchain records. As usual, the blockchain solution isn't adding anything except creating a market for the people selling it. It doesn't solve the real problems and if you spend time tackling those, you won't derive any benefit from diverting more your revenue to some VC's yacht fund.
- yellowapple 4y ago
  > The problem is that blockchains cost more From each participant's perspective they cost far less, both in terms of implementation and ongoing maintenance, than attempting to build and run a centralized database oneself (and if you're gonna match a blockchain's trustworthiness, every participant would indeed need to run a database oneself). > and add significant performance reliability problems 1. Nothing beats the performance of /dev/null. 2. They do the precise opposite of adding reliability problems; they're in fact notoriously difficult to bring down given the sheer degree of data replication. > without adding trust. The comment to which you replied describes at length how they add considerable degrees of trust. They only "don't add" trust if - again - every participant is running one's own database, at which point - if they're expected to agree with each other - you've got an ad-hoc, informally specified, bug-ridden, ludicrously expensive version of half of a blockchain. > If my inspector is being paid off, he'll do the same thing for the blockchain record that he was doing with paper. Which would then be public and uncensorable evidence against that inspector. > If things are being tampered with in shipping, the same people will do the same things and you'll have the same dodgy goods arriving at their destination except they'd now have valid but inaccurate blockchain records. And that inaccuracy would - upon detection - become public and uncensorable evidence against those tamperers.
  - acdha 4y ago
    > From each participant's perspective they cost far less, both in terms of implementation and ongoing maintenance, than attempting to build and run a centralized database oneself This comparison isn’t valid: you’re using a shared blockchain service with high transaction costs but then saying the comparison can’t use a shared service. > 2. They do the precise opposite of adding reliability problems; they're in fact notoriously difficult to bring down given the sheer degree of data replication. So you’re saying I can process blockchain transactions without a reliable, high-speed network connection? I never have to worry about fee increases or high volume impacting my clearance time? > The comment to which you replied describes at length how they add considerable degrees of trust. It describes a number of distractions from the core problem but doesn’t solve any of the hard ones. The fundamental misunderstanding you and the poster are operating under is that this kind of system is based on anonymity. Since the real world is not, you don’t need anything which PKI doesn’t give you far more efficiently. > > If my inspector is being paid off, he'll do the same thing for the blockchain record that he was doing with paper. > Which would then be public and uncensorable evidence against that inspector. Just like it is currently, except with hefty transaction fees. The problem here is that you need someone to figure out where things are being faked in-person. A blockchain can't solve that because the problem happens in the real world and if you setup an oracle to inject that information you're just renaming that existing trust relationship, not removing it. > > If things are being tampered with in shipping, the same people will do the same things and you'll have the same dodgy goods arriving at their destination except they'd now have valid but inaccurate blockchain records. > And that inaccuracy would - upon detection - become public and uncensorable evidence against those tamperers. Just like it is currently, except with hefty transaction fees. Again, “public” isn't relevant — all of the parties already know each other and if it goes to court they're going to produce records — and “uncensorable” is just meaningless blockchain marketing fluff because that's not a relevant problem or one which a blockchain effectively prevent. In all of the cases I outlined, the problem requires real world checks to find who is faking the records. Whether those records are paper, actions tracked on a website, PKI signed documents, or transactions recorded on a blockchain is a rounding error on the difficulty of setting up the real world legal system and monitoring which actually prevent cheating. If I have a problem with counterfeit goods showing up, everyone involved is going to say that their records were accurate and the problem must have been somewhere else – all a blockchain tells you is that you paid more to store the receipt, not that it was accurate.

acdha 4y ago

The problem is that blockchains cost more and add significant performance reliability problems without adding trust. You could solve this problem using PKI with orders of magnitude lower computational and storage cost, and that'd remove the requirement to have an always-on network service. However, that's still missing the point that this is fundamentally a problem about humans in the real world and the technology can't magically change that. The problems with supply chain authenticity aren't a question of record keeping but whether those records are accurate. If my inspector is being paid off, he'll do the same thing for the blockchain record that he was doing with paper. If things are being tampered with in shipping, the same people will do the same things and you'll have the same dodgy goods arriving at their destination except they'd now have valid but inaccurate blockchain records. As usual, the blockchain solution isn't adding anything except creating a market for the people selling it. It doesn't solve the real problems and if you spend time tackling those, you won't derive any benefit from diverting more your revenue to some VC's yacht fund.

yellowapple 4y ago
> The problem is that blockchains cost more From each participant's perspective they cost far less, both in terms of implementation and ongoing maintenance, than attempting to build and run a centralized database oneself (and if you're gonna match a blockchain's trustworthiness, every participant would indeed need to run a database oneself). > and add significant performance reliability problems 1. Nothing beats the performance of /dev/null. 2. They do the precise opposite of adding reliability problems; they're in fact notoriously difficult to bring down given the sheer degree of data replication. > without adding trust. The comment to which you replied describes at length how they add considerable degrees of trust. They only "don't add" trust if - again - every participant is running one's own database, at which point - if they're expected to agree with each other - you've got an ad-hoc, informally specified, bug-ridden, ludicrously expensive version of half of a blockchain. > If my inspector is being paid off, he'll do the same thing for the blockchain record that he was doing with paper. Which would then be public and uncensorable evidence against that inspector. > If things are being tampered with in shipping, the same people will do the same things and you'll have the same dodgy goods arriving at their destination except they'd now have valid but inaccurate blockchain records. And that inaccuracy would - upon detection - become public and uncensorable evidence against those tamperers.
- acdha 4y ago
  > From each participant's perspective they cost far less, both in terms of implementation and ongoing maintenance, than attempting to build and run a centralized database oneself This comparison isn’t valid: you’re using a shared blockchain service with high transaction costs but then saying the comparison can’t use a shared service. > 2. They do the precise opposite of adding reliability problems; they're in fact notoriously difficult to bring down given the sheer degree of data replication. So you’re saying I can process blockchain transactions without a reliable, high-speed network connection? I never have to worry about fee increases or high volume impacting my clearance time? > The comment to which you replied describes at length how they add considerable degrees of trust. It describes a number of distractions from the core problem but doesn’t solve any of the hard ones. The fundamental misunderstanding you and the poster are operating under is that this kind of system is based on anonymity. Since the real world is not, you don’t need anything which PKI doesn’t give you far more efficiently. > > If my inspector is being paid off, he'll do the same thing for the blockchain record that he was doing with paper. > Which would then be public and uncensorable evidence against that inspector. Just like it is currently, except with hefty transaction fees. The problem here is that you need someone to figure out where things are being faked in-person. A blockchain can't solve that because the problem happens in the real world and if you setup an oracle to inject that information you're just renaming that existing trust relationship, not removing it. > > If things are being tampered with in shipping, the same people will do the same things and you'll have the same dodgy goods arriving at their destination except they'd now have valid but inaccurate blockchain records. > And that inaccuracy would - upon detection - become public and uncensorable evidence against those tamperers. Just like it is currently, except with hefty transaction fees. Again, “public” isn't relevant — all of the parties already know each other and if it goes to court they're going to produce records — and “uncensorable” is just meaningless blockchain marketing fluff because that's not a relevant problem or one which a blockchain effectively prevent. In all of the cases I outlined, the problem requires real world checks to find who is faking the records. Whether those records are paper, actions tracked on a website, PKI signed documents, or transactions recorded on a blockchain is a rounding error on the difficulty of setting up the real world legal system and monitoring which actually prevent cheating. If I have a problem with counterfeit goods showing up, everyone involved is going to say that their records were accurate and the problem must have been somewhere else – all a blockchain tells you is that you paid more to store the receipt, not that it was accurate.