Hacker News new | past | comments | ask | show | jobs | submit login
Blockchain: A Better Way to Track Pork Chops, Bonds, Bad Peanut Butter? (nytimes.com)
108 points by Osiris30 on March 19, 2017 | hide | past | favorite | 55 comments



Seems to be hype from MBA types who've lost the technical knowledge. Or perhaps never had it.

What is blockchain? It's a way to create a global ledger without trust.

What do you need to track your pork chops? A ledger.

What is IBM? A huge, trusted, corporation.

Does anyone think if IBM operated a bog standard database of pork chops that the users would not trust it?

Every few months I'm reading these articles about using blockchain, which is pretty clever, for something that doesn't require it.


IBM might be able to do this as long as they're not also trading in the same markets that are running on their supply chain database. Fwiw JP Morgan tried to create a global supply chain database back in the 80s but it never took off. Few parties were willing to give JP Morgan such a clear view of their operations and the overall market, knowing that whatever it saved them in efficiency and better trade financing, JP Morgan would find ways of extracting value in the markets, likely at the participants' expense.


> Fwiw JP Morgan tried to create a global supply chain database back in the 80s but it never took off.

Interesting. Do you have some pointers for more information on these efforts?


IBM, JP Morgan, et al. are developing private blockchains with the aim of cheap, semi-distributed consensus and uniformity. That is what it provides over an SQL database.

Take for instance the options contract market. Let's say you have a pool of 50 trusted brokerages and financial institutions that rapidly trade these contracts. The current solution is each entity has their own custom, internal tracking system along with either a centralized service that they all communicate with, or inter-party connections. In either case, this is fragile, highly expensive to build and maintain and is often slow.

The blockchain isn't a miracle technology like these articles portray it as, and IBM, JP Morgan, et al don't see it that way anyway. It is a convenience tool for a more robust ledger that will lower costs for trusted inter-party transactions.


Private blockchains make no sense whatsoever. The only advantage of blockchains over traditional consensus algorithms is Sybil tolerance. Private blockchains, lose out on that advantage will still taking on all the disadvantages of the blockchain.


The top public blockchain that could be used to track pork chops - Ethereum - has been proven to be fundamentally insecure.

If there is a benefit in using blockchain to track pork chops, and if all the pork chop companies know and kinda-trust each other already, a private blockchain could keep the hackers out and implement various security schemes, and maybe even have a board that could publicly organize a rollback to undo a "DAO-hack". (As seen with Ethereum, such a "board" exists implicitly anyway even in a public blockchain system).


The ability to rollback "bad" transactions would be key in being able to comply with legal requirements, resolve contract disputes, etc. Plus having Sybil proof systems require PoW or PoS both of which could be difficult and inefficient for a market specific solution. E.g. why would people want to run a miner for pork chop trading? PoS might work though but still requires a founding core group that's trusted IMHO.


When was Ethereum proven to be insecure? It was proven that not all third party applications built on top of Ethereum are secure. That doesn't prove that they can't be secure. Arguing that Ethereum is insecure because a contract written on top of it had a bug is like arguing that the US dollar is insecure because a bank storing it was robbed.


I meant the third party applications (which a pork chop tracking system would be). The pure blockchain crypto should be safe.

But do you enjoy reading something like this [1]? Can you analyze blockchain code like that? Ideally before you know that there's a bug?

It's on Ethereum to show how to make things secure. The general level of software buggyness is inacceptable if you say "code is law".

[1] http://hackingdistributed.com/2016/06/18/analysis-of-the-dao...


Well, that's the only advantage of proof-of-work secured blockchains. There are strategies that use something blockchain-like for simple distributed consensus, which do have advantages[1] (and also disadvantages) over other approaches to distributed consensus.

1- The main advantage over something like Paxos or Raft is simplicity. There are also serious disadvantages, and normally I would still suggest grabbing a library that does Paxos or Raft instead of something blockchain-based. Still, it's not "no advantage".


Still, even with that difference, they have the big advantage(for managers) of having their security tested(to some extent, it is a different implementation) at such a large scale at bitcoin.


The implementation is what needs to be tested. Consensus algorithms are generally proven rigorously (given certain empirically verifiable assumptions).


Proven? that's great.

You're right, from a technology point of view. But for this system to run, you need to convince a lot of people, from different cultures/backgrounds, to use it.

Maybe talking about the safety of the bitcoin network instead of a mathematical proof makes that marketing challenge easier ?


Something that confuses me about this blockchain hype. I was under the impression that it's the distributed nature of crypyo-currencies that makes them secure as opposed to the blockchain alone? It doesn't seem like it would be that hard to re-calculate >1M sha256's to rewrite the chain if it's all a system owned/controlled by one company. Am i missing the point?


Yeah,you also need enough people willing to mine (and spend a lot of money doing so) your pork chops blockchain, otherwise anyone could come along and do a 50% attack.


Yeah. Isn't this a major problem with all of these alternative implementations? The 50% problem will always be an issues in small deployments.

It's still a problem in the largest deployment. Does anyone have a "solution" to this?

In this specific case, it seems like what they really should do is have a set of trusted nodes for ledger replication.


Surely the best antidote to the 51% attack is to have a large population of nodes so that an attack would have to be prohibitively large?

W.r.t. having a set of trusted nodes, that's fine, however does the blockchain add anything in this situation?


No. That's actually my point. This industry probably doesn't want to invest in always having 51% of the nodes, so trusted central ledgers makes more sense to me.


The solution is to not use PoW.


Private chains don't depend on PoW.


Isn't PoW the defining characteristic of a blockchain?


Just to give a bit more detail with a blockchain you need some way to limit who can create a new block since you can change history by building a chain on an earlier block if you can create as many blocks as you want. In public networks this is hard since people can create as MD Danny accounts as they want so PoW which limits who can submit by resource usage or something similar is needed. In a private network you know all the participants so you can achieve the same result with something as simple as round robin.


To me that feels like just a general consensus database problem, which has been solved a long time before bitcoin came along and "blockchain" gained mindshare. It appears "private blockchain" is mostly trying to ride the buzzword hype if it doesn't incorporate the new ideas and solutions that Satoshi presented, which is mostly about generating consensus for a ledger among a set of anonymous and possibly hostile peer-to-peer nodes on a public network?


Right so it's just a different way to solve the problem.

Satoshi didn't coin the term blockchain and they existed for a long time before bitcoin so giving him sole claim to it because it paired it with a feature that isn't specifically required to have a blockchain seems silly.

That said I do agree that their are a lot of buzzword vultures using it at the moment for stupid business ideas though I think 99% of the bitcoin business ideas are poorly thought out and poor replacements for existing solutions("but with bitcoin!") so it's no surprise 99% of the blockchain ones are too.


No, it is just a good(the best?) way to do public blockchains.


You can do Proof of Authority instead of Proof of Work to cut down costs.

The real reason behind techniques such as PoW instead of just Distributed Byzantine Fault Tolerance algorithms is scaling in terms of number of validators. Most of DBFTs (afaik Algorand is the only exception) don't really scale. Proof of Authority behaves similarly to PoW, since it also does not have that problem.

Go with DBFT unless you want to have huge number of validators.


That's a valid point. I suppose the whole blockchain idea has several modular interchangeable parts though, including deciding what chain is authoritative, who can mine a block, and so on.

In the original form though, it makes no sense to fire up your own bitcoin, because when it's small it's vulnerable to the attack you mention.


There are different ways to limit who can write to a chain at the current time to reduce overhead. PoW is just the most popular(are arguably the best for public chains). Private chains don't need that since you know all the participants you can do something as simple as round robin.


Companies don't want to use an 'IBM blockchain'; they want their blockchains, with the data inside and the chaincode specific to their business logic, fully on-prem. And chances are higher than not that these blockchains will operate inside an adversarial environment. With a BFT-enabled blockchain (Hyperledger can be this), there isn't a need for trust at any business layer. That best represents the current state of many global supply chains today - there isn't a lot of trust in this business.


Block chains are at best only secured as much as the hash power to generate them. If your spending 1M / year generateing a block chain it takes about that much hash power to break it.

This creates a vast overhead as you can't secure a billion+ dollar market without massive and continuous investments.


You're wrong. Most enterprise blockchains use BFT algorithms or even round-robin instead of mining. What they are after is a highly auditable shared computing environment.


You can use things that are not a distributed block chains.

But if you have some trusted party just use a DB.


The use of PoW isn't what makes a block chain a block chain. The idea is that you don't have a single trusted party you have a collection of them that need to collude to cause harm to spread the required trust.


Surely the trust issues in global supply chains - involving making and shipping physical products often subject to regulatory oversight in multiple jurisdictions - are much bigger than "the database isn't mutable"? Ultimately, a blockchain database can lie just as much about the quantity and quality of what's being shipped as a transponder which all interested parties can track on their own non-blockchain auditing systems.


One of the attractive features, as I understand it (which is quite superficial) is that there is traceability --so that if I were a recipient of some kind of subsidy/assistance those monies received could be tagged for certain things like say rent, food, medicine, but not vice, or entertainment. Of course, that does not prevent someone from receiving such 'traced' good and bartering them, but it adds a disincentive.


I agree that the blockchain is a whole lot of overkill for these applications. I think people have to realize that blockchains are only justified if parties don't trust each other or their communications channels. It's a solution for Byzantine consistency. If you don't have Byzantine consistency problems, just use Paxos or Raft.


Neither of those systems would scale. Have you ever heard of a paxos/raft scaled beyond ~9 odd members in production?

Blockchain's also provide data redundancy and security between entities. It'd be way more effective way to communicate commodities, medical records, etc as the security, data model, and system API are all integrated into the blockchain model.

Having the "database" be the API would be great for those of us dealing with supply chain. Want information from your supplier in Shenzhen? Good luck with current systems! Paxos/raft do nothing to resolve data access and verification.


Do you think this is a function of marketing, or genuine ignorance as to what can be accomplished? (Or both?)


It's a function of people not digging into the technical details.

If you don't do that it's easy for your idea of what something is to morph into something sexy that's the best thing since sliced bread. Also it's a function of non technical people having a brainstorming session. They pat each other on the back for taking this thing to the next level, which is actually the previous level.


I see... your description reminds me of how I thought about physics when I was 9. I was big on the "wonder" of it, light on the math and the science. I can see how enthusiasm and ignorance would be a potent combination, without any dishonesty entering into the equation.


I think you are right. The older I get and the more people I work with I realize that most people are just ignorant. They come up with a "good idea" based on their ignorance and then push it. I know what it is like, because I have done it in the past, and still have to check myself even today. The best way I have found to combat this sort of situation is have a core group of trusted friends with various backgrounds. They will be the first to let me know my "good idea" is actually a bad idea and usually point me in the right direction to educate myself.

The problem is in the corporate world there is no trust. People seem to get the notion that if you use facts to show them their idea is bad that it is some sort of personal attack. Or worse, there are those in the corporate world that can spot a bad idea and not say anything -- only to watch it fail.


This is even more problematic in remote jobs (work from home). Most communication is non-verbal and much easier to misunderstand the writers true meaning/intentions.

Even without that, its a confounding problem for me. Im always doing those things: asking questions either to genuinely learn or to ferret out possible mistakes, pointing out errors, sharing better methods/techniques, etc. I just cant help it, and while I try hard to word things in a constructive manner, to make sure it IS constructive, more often than not I think it is taken poorly.

I want the same criticism of my own work, but I still often have a difficult time with it myself, though I recognize the signs as the knee-jerk reactions that they usually are, and seem to get better at that every day.


I have a feeling that blockchain is more of a solution in search of a problem. Blockchain is really a clever thing and it amazes me in many details e.g. specially when looking at bitcoin. But it still doesn't convince me where else it could be successfully deployed. By this I mean: in which domain we really need all of those guarantees of blockchain and at the same time accept all the disadvantages.


A blockchain might be overdoing it. Also, does it really provide a guarantee against companies buying cheap and uncontrolled raw materials from e.g. China and mixing it through our food?


I get the feeling that the blockchain is the solution to all the problems, just like IA. I think it's getting overhyped too much.


Isn't it so difficult to grasp that you need a blockchain only and only if you want to avoid trusting someone in a (meaningful) transactional system? And you're ready to pay the price.


I have an idea for a FOSS blockchain-based system that allows anonymous reputation tracking through tokens to provide an alternate API for trusting anonymized users through CDNs, portals, etc. Generating, storing and sending the tokens can be automated and transparent.

The premise is that if your calculated reputation isn't above a certain score, servers can choose to disregard or throttle your requests. Servers can update your rep on the blockchain via a provided OTP, based on user behavior. The higher your rep, the less likely it is that actions interpreted as malicious will sever or throttle your connection.

The big technical challenges I see would be mitigating abuse from both malicious clients and servers. Visit a malicious server and your rep is harmed. Weighting all past scores could mitigate this issue. Combining a gradient descent algorithm for adjusting reputation with a "time-out" mechanism could possibly mitigate the incentive for botnets to farm good tokens to sell to malicious users. The other big challenge of course would be user adoption.

This could be a robust way of dealing with DDoS attacks and botnets in the increasingly anonymized web. It could create an accountable web of trust for anonymous authentication, as it would take time and effort to create and maintain more than a few trustworthy private tokens. Any blockchain experts care to chime in?


Er, privacy? From what you're describing it sounds like you'd be building a giant public database of users' browsing habits, which should raise some eyebrows.

The fact that it's structured as a blockchain makes it worse, as there's no way to age out data.


Blockchain-based, so pure bitcoin-style blockchain implementation isn't necessary. It probably wouldn't be that big of an obstacle adding a trimming mechanism by, for example, maintaining a group of sub-chains.

To limit the granularity of data being stored, it would only be used at authentication endpoints, to create a private session. Once you've identified yourself as reputable with a OTP that doesn't reveal anything about your actual internal ID, you can transfer secrets and further authentication is not necessary.

The system would employ paranoid homomorphic encryption [0] and a fuzzy API. Hardly a worthwhile vector for analysis compared to the standard MitM attacks applied today by state agencies and ISPs.

[0] https://en.wikipedia.org/wiki/Homomorphic_encryption


I think the problem runs deeper than you're considering. The entire purpose of this service, as you're describing it, is to allow web sites to access information on what other sites their users have visited (and, presumably, to read "reputation" annotations made by those sites), and to use that to make access control decisions. The privacy violations involved are inherent to that purpose; you can't wipe them away by throwing "but with encryption" at the problem.


I don't mean to shut down your criticism, but how does it present a vulnerable security model?


Privacy is a component of security. Systemically violating your users' privacy is a security issue -- period.

If your "security models" don't recognize this as an issue, you need to change those models.


Privacy and security are two separate domains. But even then, how does this violate anyone's privacy in any way that existing authentication protocols do not?


check out Hyperledger for a FOSS blockchain community of projects: https://www.hyperledger.org/


tl;dr no.

I literally put up something about this just this evening: https://davidgerard.co.uk/blockchain/business-bafflegab-but-...

Many blockchain schemes promise the magic of full availability of properly cleaned-up data. The actual problem in every case is cleaning up the data in the first place; the barrier that such efforts founder on, over and over, is that no industry’s players want to create such a new monopoly. The proponents’ business goal is usually to become the organisation effectively controlling the newly cleaned-up data, with a monopoly maintained by network effect.

If your big goal is cleaned-up data across multiple organisations, the approach that will get you there is creating a data schema that is so obviously and elegantly the right thing that everyone just adopts it themselves, and a regulator eventually says “hey, use this schema.” Note lack of blockchains. (This is the usual approach in computing, though even there companies routinely try to set themselves up in the role of central octopus.)

Supply chain provenance is a perennial proposed use case. e.g., Provenance, Inc. is a London startup who offer to put data about tuna catches on the Ethereum blockchain. They claim to offer supply chain transparency to all participants, and this will reveal illegal overfishing or fishing that involves human rights abuses. The actual problem turns out to be no agreement on what data to collect or what to do with it. The data would still be entered by local humans under the auspices of “trusted” local NGOs – who would be paying monthly for the necessary software – on the apparent assumption that commercial operations engaging in illegal overfishing or human rights abuses will certainly carefully document their human rights abuses in the blockchain and not have strong incentives to just lie or something, or bribe the “neutral” adjudicators, as already happens in current supply chain monitoring. The main byproduct of this sort of scheme is a monopoly for the traceability provider, i.e. Provenance.

As IBM found out after starting Hyperledger, all manner of businesses – financial institutions, beef industry, shoe brands, confectioners – don’t want to share data even with all participants in their blockchain, but only with the people the specific deal is actually with. Funnily enough. This was apparently news to them. It turns out that IBM set up an elaborate hammer design consortium without first finding out if there are nails.

The precise same considerations, goals and problems will apply in this case. In all these schemes I've seen to date (and let me assure you I've read horrible PDF whitepapers out to here), the aim of the scheme is to sell someone thousands of contracting hours by convincing them you can help them become the controlling octopus at the centre of their industry.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: