Hacker News new | ask | show | jobs
by hacknat 2983 days ago
I think all the hype around block chain is hilarious for the very simple reason that block chain can’t actually solve any business problem that a centrally managed service couldn’t solve (with less effort likely).

The only thing block chain adds to any problem is when you don’t want a managed good or service to be under central authority or if it can’t be under a central authority (the later situation is probably more interesting). Crypto currencies make some sense (though I like my currency backed by the full faith and credit of a government, personally). However every other situation I hear of I wonder why someone couldn’t just manage a central service. Chain of trust on crates of produce? Supply chain professionals have solved the problem of authenticating sourcing of goods quite a long time ago (especially when laws required them too). Personally I think the one benefit that people don’t talk enough about is cases where the block chain can provide its users perfect forward secrecy on their transactions against the ledger, though again you don’t really need the block chain to do that.

2 comments

> The only thing block chain adds to any problem is when you don’t want a managed good or service to be under central authority or if it can’t be under a central authority (the later situation is probably more interesting).

Trust (and thus the ability to use an authority) is not black and white. There are a lot of situations where some trust is allowed up until a certain level. Right now authorities are managed through some form of government or through legal enforcement (contracts and such).

- The first one only works in specific scenarios.

- The second one is extremely expensive (especially when working across borders). It might technically be not as elegant. But generally speaking servers are a lot cheaper than lawyers. Code is designed to be extendable and reusable, contracts are not. Let's not even talk about the long process of enforcing those contracts manually with very expensive lawyers in a physical court building.

> Trust (and thus the ability to use an authority) is not black and white. There are a lot of situations where some trust is allowed up until a certain level. Right now authorities are managed through some form of government or through legal enforcement (contracts and such).

How does trust play a role in a company tracking its own inventory? What does blockchain offer in terms of trust even when working across borders?

Because for any sufficiently large company, they won't be the only entity in their inventory's supply chain. Sharing data throughout the supply chain accurately and reliably is an extremely hard problem that has yet to be solved sufficiently.

So specifically, blockchain offers a totally accurate, reliable, secure way to track and exchange data across a multitude of distinct businesses with little opportunity for corruption. I'd say that's very valuable, and NOT something that can be done with a central database.

>So specifically, blockchain offers a totally accurate, reliable, secure way to track and exchange data across a multitude of distinct businesses with little opportunity for corruption.

This is genuinely amusing to me. I feel like in these discussions you can replace "blockchain" with "philosopher's stone", like it's some kind of magical element that solves problems using the power of dreams and internet memes.

Let's imagine that we're in the real world for a second (I know, lame). Now we're in a company that deals with fruit imports. We have a ton of contractors all around the world and we use the Holy Blockchain to deal with that.

One of our contractors adds a transaction to our chain saying "we're sending you the container #12 containing bananas". Then almost at the same time an other contractor in the same area says "we're sending you the container #12 containing lemons".

How does the Holy Blockchain, Peace Be Upon It, solve this issue? Do we use PoW? Does the contractor with the most powerful computer decides who's right? If it turns out that the lemon contractor wins somehow and gets its transaction on the blockchain but it turns out they lied or were mistaken, do we tell the customers that "the code is law" and they're just eating extra-bitter bananas?

I mean seriously, it's not magic, it's a bunch of data chunks linked through a SHA-256, it's not going to bring world peace and it's not going to magically make everybody in the world agree about everything. As long as bananas won't grow directly on the Holy Blockchain (May Satoshi Grant Peace and Honor on It and Its Blocks) then nothing will ever be totally accurate, reliable or secure. Unfortunately I hear that digital bananas are not very nourishing.

> PoW

I don't know any private blockchain solution in the supplychain space that uses PoW. There are more ways to form consensus.

> This is genuinely amusing to me. I feel like in these discussions you can replace "blockchain" with "philosopher's stone", like it's some kind of magical element that solves problems using the power of dreams and internet memes.

You can use any type of software, as long as it has one clear picture of what the current status is (a database would work, 100 different databases would not work). A bulk of commodity trading is a done on paper right now, because no one wants to trust a single party to hold this database. I am not familiar with fruits but I work in soft and hard commodities (anywhere from grains to beans to oil to metals) and everyone is looking into distributed systems to solve this exact trust issue. But maybe all these companies should hire you to build a mysql database instead I guess?

> One of our contractors adds a transaction to our chain saying "we're sending you the container #12 containing bananas". Then almost at the same time an other contractor in the same area says "we're sending you the container #12 containing lemons".

Those are two different transactions, I don't know any type of software that wouldn't compute that you get 12 bananas and 12 lemons? I guess I'm not understanding what you are trying to say.

They are saying that one party says the container with ID #12 has bananas and a different party says that container #12 has lemons, not that there are two containers, one with 12 bananas and one with 12 lemons.
You are taking the argument too far, but then you probably know it.

It's just a "tamper-proof" ink for a reasonable price, nothing more, nothing less. It won't grow bananas or lemons, and GIGO (garbage in, garbage out) principle still applies.

How about if instead of coming up with the fictional scenarios that won't work, you instead learn about technology, ignore hype (and greed) and come up with the some that will work? Hint: they exist.

Please try to track the context of an argument. You're ignoring the part where simias was responding to a post which stated that blockchain is "totally accurate [and] reliable", which is in complete contradiction to your view that it's GIGO.
If its tamper proof ink can't we solve that by signing the document and emailing it?
So, you are saying sharing data through supply chain is difficult. It is difficult because data cannot be tracked in an accurate, reliable, secure way and there is corruption involved. And lastly, blockchain is the only solution to these.

How will blockchain help in tracking shipments in an accurate, reliable and secure manner and most importantly, how does it stop corruption? If possible, how about using an example for clarity? Let's say Apple shipping a new MBP from China to a customer in US. How does blockchain work in ensuring all the above features?

> How will blockchain help in tracking shipments in an accurate, reliable and secure manner and most importantly, how does it stop corruption?

We already had double entry accounting in order to establish immutable book entries but that gives us a problem of a potential multiple sets of books. The publishing of these records to the blockchain via PoW therefore establishes a sort of triple entry system where the Proof of Work idea is intending to prove a single unmodified ledger.

I work IT for a retail manufacturer. We have to track ingredients for every product we create and what products they each go into and to which customers they ship out to. I'd say it's reasonable that we trust our own database but do you? Is it reasonable for you to trust my database? What if there's a huge recall because of a tainted ingredient? What if I found out I'd lose my job or the company would fold because of this recall and maybe I was lied to and told the tainted ingredient is harmless(Im no food scientist)? I think we have enough evidence to show that companies will sometimes alter books and lie to avoid responsibility but not me no, I'd NEVER do such a thing, i'm a good boy who would never get fired for doing such a thing but maybe that's what would get me fired....fuck what do I do? Oh you meant data corruption....yea no one has double spent yet have they?

Isn't the 'trust' eroded once a single party gains 51% of compute? Then you're just a really complicated and poorly implemented centralised database.
According to some comments from the core Bitcoin devs if an attacker has 51% of the hash rate they can selectively deny other people's transactions but it takes a much higher percentage of hash to be able to rewrite the blockchain.
Using that logic, centralized systems have zero trust since single parties own 100% of the networks.
Complete opposite - A centralised system requires you to trust the single party operating it, but that's super transparent. Either you trust it or you don't, but it's clear what you're getting yourself into.

Meanwhile, blockchain networks advocate a functional network that doesn't require trust - it's kind of predicated on the fact that you _can't_ trust anyone. But if a single party obtains 51% power, you have to trust them anyway. If you're going to require trust, you may as well just do away with the whole complicated setup and be explicit about it.

51% attack is an issue that people have been concerned about for awhile. But an actor having 51% of the mining doesn't equal to poorly implemented centralized database. And a lot of ppl are keeping a look out for this issue so my guess is that even if one bad actor who happens to have 51%+ tries to hardfork, the rest of the community won't move.

There are efforts to deal with this issue. One example being the whole debate around moving from PoW to PoS and other systems.

> if one bad actor who happens to have 51%+ tries to hardfork, the rest of the community won't move.

What does that mean for Walmart and tracking their inventory?

This is the problem - these blockchain ideologists only tend to see problems and solutions from the perspective of the actual cryptocurrency blockchains. Real world is sadly a little different...
>Let's not even talk about the long process of enforcing those contracts manually with very expensive lawyers in a physical court building.

You'll still need them at the end of the day though ? Code running in a computer somewhere doesn't rule the physical social very animal side of things.

Laws and lawyers are fuzzy constructs because humans are fuzzy creatures to start with, and imo we need that flexibility in laws and in their application, hence why I don't trust the "code is law" catch phrase.

I'm not saying it applies to everything. I'm not talking about you getting into a fight with your neighbor and the blockchain will help you settle things. But when two financial companies (for example) enter in some kind of contract the majority of the work involved can be automated on a blockchain as soon as there is one they both trust. source: I've worked for banks trying to do specifically this.
Can you name a situation where the blockchain could obviate the need for lawyers?
"I think all the hype around block chain is hilarious for the very simple reason that block chain can’t actually solve any business problem that a centrally managed service couldn’t solve"

This is a very common statement on here regarding blockchain solutions, and is effectively like saying "There's no program you can't write with 1991 Visual Basic" (or build in Excel -- I've had financial sorts try to hammer every problem into an Excel workbook). Theoretically true, but outrageously off the mark given the nuance on needs of many very varied projects.

Blockchain style solutions are not relevant for many projects. They have some legitimate uses, however, and saying "But you could..." isn't a retort.

>Blockchain style solutions are not relevant for many projects. They have some legitimate uses, however, and saying "But you could..." isn't a retort.

Except you've got that backwards. Since none of those solutions actually exist yet beyond hype, it's the blockchain proponents who have to show how using blockchain technology in those situations is not only feasible but superior. Saying that you can already solve those issues with existing techniques IS the default.

No, I don't have it backwards. Blockchain solutions offer decentralized, trustless alternatives to existing centralized, trust-based solutions. Further, it's bizarre reading this constant claim that nothing exists beyond hype, when a number of orgs have operating or in testing blockchain solutions for industries from manufacturing to finance. Inertia is a hell of a thing, as is "the way we do things", so it isn't surprising that it didn't suddenly replace everything, but it does have uses.
>No, I don't have it backwards. Blockchain solutions offer decentralized, trustless alternatives to existing centralized, trust-based solutions.

The problem is that the more we look at potential use cases, the more we found that trust relations are necessary to handle a load of basic process requirements that cannot be solved by blockchains alone, thus requiring the addition of trusted actors, thus removing the need of blockchains to begin with.

Blockchains proponents tend to see trustlessness as a benefit by itself. In their view, Blockchains are better than traditional databases because trustlessness is better than traditional client-server models.

System designers see trustlessness as a constrain. If you are in a bad situation where no single actor can be trusted by everyone else, then you can implement a decentralized database using blockchains. It's going to cost a lot in term of performance and efficiencies, but it's doable. But as soon as this constraint of truslessness is removed, why the hell would you bother with something like blockchains? And experience show us that, well, there's actually not a lot of contexts where trustlessness is an absolute requirement.

Please do list a couple of useful solutions where blockchain is the right/better tool for the jobs and thats outside of crypto coins or secondary layer of payment abstraction (and even there any payment option could work better in a lot of the cases).
Property title insurance is a great example. With blockchains it should be possible to reveal the owners of all properties and all transactions in order to remove ambiguity from the system. It is true that constructing and making use of such data implies trust in some sort of organization or process, but a robust store of ownership data is currently beyond keeping of property title records as currently performed by entrusted government entities.
Why would this work better? Not to be cynical but it seems from a engineering perspective that the trade off is security for data robustness? Anyone who takes control of the network will take control of all property title insurance data. In return at least i know up time will be 100%...
Isn't it just basically triple entry accounting?

Blockchain tech is ultimately about trust. Trust that the accounting hasn't been altered. You don't quite have it solved with just a double entry ledger right?

> Blockchain tech is ultimately about trust. Trust that the accounting hasn't been altered.

A simple git repository offers this property. Really it's just any data structure where only growing it is permitted. You don't need a blockchain to get this.

The implicit part of this argument, though, is that blockchains are expensive: in order to have this trustless system you have to have PoW which is inherently computationally (and therefore monetarily) expensive. It's not going to be easier to write either (which is the reason why people aren't using 1991 Visual Basic).

In other words, the argument here is why would you do it this other way that is more complicated and/or expensive when you could do it the default way which is simpler and cheaper.