5 ms·
On the contrary, there is a there there, it just takes a tremendous effort and coordination to get to a point where it's actually useful.
by jsutton 3y ago
On the contrary, there is a there there, it just takes a tremendous effort and coordination to get to a point where it's actually useful.
- mjburgess 3y agoUseful for what? A peer-to-peer decentralised network of database nodes which is "immutable" only insofar as a peer cannot afford to outspend the network... is useful for what ? The only use-case identified so far is defeating state regulation of finance, ie., crime.
- edgyquant 3y agoSystems that require decentralized workflows
- flangola7 3y agoSuch as?
- 8organicbits 3y agoI struggle to find examples that "require" decentralized workflows. Money seems like the most successful example, although cryptocurrecy works worse than fiat in practice for most use cases. CA DMV records? Loyalty programs? What's wrong with a database? What's the requirement for decentralized workflows?
- vntok 3y ago> I struggle to find examples that "require" decentralized workflows Storing factoids that (1) can't be repudiated by anyone (including the initial reporter), (2) can support attestations in the future (I can prove to anyone that I bought something years ago without showing the thing or making myself known), and (3) can only be deanonymized if and when the user wants it to happen.
- 8organicbits 3y agoThese all sound very cool, but they still sound like solutions in search of problems. 1 - Non-repudiation can be done with cryptographic signatures. Storing signed data doesn't require a blockchain. I think the major improvement is related to time-stamping, although there's lots of prior work there. 2 - When would someone ever need to prove this? If you can't prove the "what" or the "who", how is this useful? 3 - For Bitcoin, no, there's lots of tools to de-anonymize users. For others, I think that's true, but what's the use case beyond money laundering?
- mjburgess 3y agoWhat aspect of blockchain is decentralised? Why is that aspect desirable? It's not the compute, which is abitarily centralised. It's not the code. It's not the interpretation of the data. It's the consensus of which dataset is the valid one. That "consensus" is dependent on the nodes which form it being honest and not being outspent. That's kinda insane right? Why make which version of a dataset is the right one dependent on adversarial peers with malign economic incentives? Oh right, because you're trying to brute force your way to an alternative economic system. That's the only use case of this mixture of technological absurdities -- and it's a dumb one which will disappear on contact with regulatory oversight. Blockchains distributed consensus model *is* based on contingent economic incentives. This isnt a "technology" is a peer-to-peer data validation network which works only insofar as it can bribe its participants.
- s1gnp0st 3y agoWhat of the crime of indirect taxation via unlimited monetary expansion which disproportionately hurts the poor and helps the already rich?
- nathan_compton 3y agoTo the extent that this is an accurate characterization of the status quo, its a social problem, not a technological one. No amount of technology will save us from power and its abuse and, in fact, the idea that technology will save us from the problem of building and participating in a just society is, in my opinion, part of the spectacle that keeps us docile in the face of power.
- s1gnp0st 3y agoI have no interest in your idea of a just society, nor in my compulsory participation in it.
- flangola7 3y agoThat is a social problem you solve with social solutions - progressive taxes, UBI, comprehensive safety nets, etc. Silicon valley has this perverted obsession with applying technological solutions to societal issues. They have phenomenal hammers, but not everything is a nail.
- mike_hearn 3y agoAs someone who built a platform for business/governmental 'enterprise blockchain' apps, humor me whilst I mount a defense of them here. Firstly, forget all about outspending the network. None of the platforms an organization like the DMV might consider use proof of work (I'd hope). Standard within that space are BFT algorithms, or even non-BFT algorithms like Raft, or even a simple centralized DB (but which only holds tx ordering info, not the actual tx contents themselves). Enterprise blockchain platforms try to solve the following problem: there are many situations where different organizations would benefit from a proper digitization of a business process, but it doesn't happen because the political/business costs of placing one organization in control of that process is too great. In turn that requirement comes from the software industry only delivering systems that assume one party controls everything. If the business process you're automating exists entirely within an organization, or if you can get all the organizations to buy into a single platform company, then it works. If those two things aren't true then we got nothing for you and so you end up with "digitized" processes that often are little more fancy than emailing PDFs or XLS files around. Or the government steps in to provide something at which point the ability to innovate or evolve that process grinds to a halt, because their only goal is system stability and not feature development. One thing to note here - I learned whilst working on some of these projects that whilst they may sometimes appear nonsensical on the surface, that was usually due to lack of domain knowledge on my part. For example there was a project to try and put land registration in the UK "on the blockchain" (concretely, using the platform I worked on) and so I asked early on whether this really made sense because, surely, the government is the central point of truth for land ownership? Where's the inter-organization aspect? Well, guess what, turns out there are tons of obscure business processes around the buying and selling of land in which the land registry plays a key part, but it's only one organization amongst several, and a big part of the schlepp-work here is coordinating all those organizations and moving documents (i.e. hand written database transactions) between them. Once the domain experts walked me through those processes in detail and explained what they wanted, I realized it wasn't nonsensical at all. There were a lot of cases like that, where in theory I was selling the tech to them, but in reality they were explaining the need to me. So what to do? These problems would go away and the impact of IT would be much greater, if we had two difficult-to-make things: 1. Some sort of multi-master database system in which the masters didn't trust each other, which could work together over the internet such that each company or organization could run a node themselves. 2. Social institutions that could set up and make use of such systems without any one party gaining too much power over the others. Due to the enormous pre-existing demand that existed for automating all these difficult-to-automate business processes, when people realized that Bitcoin basically worked by solving (1) and to some unclear extent also (2), they jumped on it. Except of course the whole design philosophy of the tech really wasn't what they needed or wanted, hence the evolution of dedicated platforms like Corda that tossed out proof of work, added conventional tech like X.509, per-node RDBMS and so on. Now in practice a lot of these projects fizzled out, which is one reason why we get threads like this one on HN. Having seen a lot of these projects in action, the issue was really that both (1) and (2) were never fully solved. For (1) the tech problems are hard because it's all the difficult bits of distributed computing and distributed databases, with lack of trust thrown in on top, combined with really difficult deployment environments (like banks), combined with many of the platforms advertised to such projects going off into the technical weeds with things like new programming languages. But the tech issues pale in comparison to (2), the social difficulties of coordinating multiple institutions in the design and implementation of complicated IT projects. In fact that was by far the hardest part and in the end the real sticking point. Without capitalist ownership incentives projects don't make progress - look at IRC vs Slack for a particularly stark example - and so often these projects got spun out into startups. But then you're back to relying on a third party. At first it didn't seem like too much of a compromise because they would just write the software, and the institutions would at least run it so the startups wouldn't get everyone's data like in a classical SaaS situation, and the platforms were designed to allow for some level of divergence and forking. But then often the customers started running out of steam and just wanted to pay someone else to run it all, so it degraded back down to being SaaS but with more overhead. In the end the thing that stopped most of these projects being successful wasn't that the core problem statement was wrong, or even that the tech wasn't good enough (though sometimes it struggled to meet people's needs). It was actually that most non-tech orgs have developed an unwritten cultural rule of institutionally "sandboxing" tech projects to avoid the potential for career damage when they inexplicably blow up (due to mismanagement but the people involved often don't realize that). For as long as projects are confined to the sandbox marked "innovation team" everyone is happy. When it comes to real implementation, the executives start looking for ways to outsource it all so if things go wrong they can point the finger at the vendor - they want "one throat to choke" in the lingo. This dynamic causes organizations to diverge. Either they successfully make the transition to being a sort of tech company, in which case they want to own all the platforms and probably can, or they become hollowed out customers of vendor's pre-packaged business automations in which they experience less career risk, but struggle to differentiate.
- hn_throwaway_99 3y agoYour response here, and a lot of the supportive responses to it, highlight what I find so aggravating about the crypto/blockchain community: no explicit, discrete examples, just a lot of hand wavy "oh, it takes a lot of work but when it comes you'll know it!!" wishful thinking. Top that off with the common (you aren't doing this BTW but I see it all over HN) "See how the HN hivemind just hates crypto!" whenever sceptics ask for explicit, unambiguous details on the utility of the technology. I'll play devil's advocate, because I do actually think there is one place blockchain could be useful: as a backend settlement layer for financial institutions. If you ever get into things like banking or credit cards, you'll find that our current settlement technology is kind of insane - it's basically a digitization of paper file driven processes from 70 years ago. Things like big clearing houses are largely necessary as a result of these processes, and I could see blockchain obviating some of that. Even then, though, it takes blockchain from being this "changing the world technology" to a relatively minor efficiency improvement. I also still wouldn't bet on it, because even though the existing system is complicated and crazy, it still works, and it's not totally clear to me that existing players have enough incentives to actually change the system.
- jsutton 3y agoThere's been a few examples of use cases said by others in this thread, and your financial settlement use case is a great one. Any time you need to move money around multiple parties based on a clear set of rules or criteria, blockchain could be useful. Insurance claims, international remittances, lending, to name a few. Anywhere a valuable process is still dominated by paper (and there are surprisingly many). Generally, being able to program the management of money (i.e. if personA meets a certain criteria, send $X to personA) in a transparent system can be incredibly powerful.