memes

[Continued from the other reply]

So I take it you agree blockchain solution is not trustworthy in itself, then?

Data internal to the blockchain is 100% trustworthy, otherwise new blocks could not be verified.

Verifiability is not the same thing as trustworthiness. I believe I already said that.

External data added to a blockchain is transparent and traceable, but requires additional verification to be considered trustworthy. Fraud is identified by these additional non blockchain processes.

Which is a long way of saying organisational solutions are needed for organisational problems like trustworthiness.

By the way, again somewhat unsurprisingly, nothing stops centralised system from being verifiable and immutable. There's one massive example of this: Git.

Git is decentralized. Everyone has a copy.

But not every Git repository that is cloned elsewhere is meant to stay identical. If anything, it's more of a federated system than a decentralised monolithic system, with each of the clones just doing their own thing.

Git repositories can work independently and local branches can do local things. Nothing in it forces everything to be committed to a "single ledger". Nothing about Git works on technically enforced "consensus". It just gives users the ability to make sure that if they choose a common branch, then they have the ability to build on that.

If you enforce signing of git commits and only accept data in commits that follow strict rules linked to signers public keys, and create a mechanism to eliminate forks, then you have a blockchain.

But nobody implements it that way. Especially the part about eliminating forks. The ability to create forks and branches in Git repositories is considered a feature.

In blockchains, they're considered undesirable, yet they happen anyway, because of bugs and users and developer meddling.

Again, you really shouldn't be going "well, this solution based on decades old technology kinda looks like blockchain if you squint a little bit."

Follow this thinking to its logical conclusion for an industry wide database/computer where actors can join at will, and you will end up designing a blockchain.

Or you don't! Based on the above, if someone manages to build a system like that without blockchain, I'm sure you'll be there saying either "well they should have built a blockchain" or "it kinda vaguely looks like blockchain to me".

I'm trimming this a little bit so that I don't have to repeat myself that much.

But it doesn't solve these problems. It's one thing to say that maybe blockchain can give you tools to facilitate intraorganisational problem-solving. It's entirely another to say that it solves the problem. That's salesman talk, not system designer talk.

Now it's the English language you are picking a fight with?

No, I've just watched marketing making unfounded promises long enough. Unfortunately, not a new problem in the software sector.

Like I said, blockchain proponents have way too many hand-waving hype salesmen and not enough people who think of the problems comprehensively.

I will happily state that Excel solves my accounting problems.

Good for you. A lot of businesses use Excel as a tool that is part of the business process. Maybe I'm using it wrong, I just get an empty worksheet when I start it up. It doesn't actually solve my problems unless I actually interact with it.

Zero Knowledge isn't a "blockchain" solution, it's just a cryptographical solution.

It is blockchain compatible.

Also compatible with everything else. So as we've seen in this discussion, it's not inherently a blockchain advantage and blockchain doesn't help or hinder this any way.

the solutions they're talking about are cryptography fundamentals that predate blockchain stuff by decades

But it took decades for someone to realize that these technologies could be covid combined.

You're reciting that like some kind of religious history, St. Satoshi's Idea That Changed The World As We Knew It.

While in the actual reality, invention of blockchain was little more than an interesting chapter in the big history book of cryptography.

Neural networks were first proposed in 1944

And were use in decades. Much like individual cryptographic concepts. This is all evolutionary leaps, not revolutions.

And, of course, it's functionally equivalent to the company staff sanity checking things

Not at all. The proof is entirely separate from the underlying data.

But company employees sanity checking the business data is also separate from the underlying data. They can hire independent auditors if something really fishy is going on. What are you getting at?

Just because you have a trusted adjudicator doesn't mean deliberate fraud doesn't happen.

It's game theory. The only thing an auditor really sells is their reputation.

And as we've seen from history, reputation doesn't matter when there's enough money on the line. As we have seen from cryptocurrencies, people are perfectly willing to sacrifice their integrity and abscond with ridiculous amounts of money.

Incidentally, same goes with the technical solutions. Need I remind you what happened with The DAO and Ethereum in 2016? Someone messed with the blockchain, so the blockchain developers messed people back?

If you don't set up any authentication for particular items, then how do you control access?

Pre defined rules set by smart contracts.

But smart contracts are just software (running on mining nodes) operating on data (in the blockchain). How do you control the access to the data?

And can't this be implemented more efficiently on centralised services anyway?

Isn't setting up access control by definition dependant on some kind of authentication?

No. You don't necessarily need to know anything about whoever is interacting with your blockchain.

So why set up access control then? If you don't care about who is interacting with the system, why have access control? If you actually do care who has access to the information after all, how do you do that without authenticating?

And in what sense is this different from traditional publishing systems? If the information is available publicly, then it doesn't matter to the publisher who is accessing it?

If the users aren't identified, how is this different from the information being available publicly?

Because the information is limited to a subset of users, who's identity is not needed.

But how do you limit the information to a subset of users without authentication? If their identities are not verified, how do you know how to limit that information to that set of users?

How do you create an "user group" without specifying who the users in the group are?

More importantly, how is this enabled by blockchain specifically?

Via private keys and hashed data.

...If the users in fact do have keys, then that's just access control and user identities, isn't it? You can't issue people keys without knowing who they are, right? Otherwise it's no different from information being available in public, because then the keys can only guard the integrity. You've invented TLS from ground up. (Blockchain proponents reinventing old cryptography concepts and calling it a blockchain revolution really isn't surprising.)

Nothing stops people from using private keys and hashed data on non-blockchain systems. That's just bog standard identity management. So this isn't a specific blockchain solution, which was what I was asking about.

public blockchains obviously have no access control whatsoever, the entire ledger is public, duh.

Smart contracts control access on a case by case basis. Only the hash of the data is registered on the blockchain.

Smart contracts are just software that have distributed execution on the mining nodes. They don't inherently implement access control any better than software that is run on the servers elsewhere.

Can you give me concrete examples of this kind of system in use?

Commitment scheme

Oh wow, a cryptographic concept from 1988.

Anyway, that's not what I asked for. I asked for concrete examples of a system in use. Is this actually in use anywhere in a blockchain system? How does it work in practice? I'm genuinely curious.

This can be done much more efficiently by just mirroring the data directly.

That's exactly what each full node does.

Yes, exactly! Except less efficient, like I said.

The node also checks that the current state is coherent which is a stronger requirement than a database mirror.

Dunno, modern distributed database folks spend quite a lot of time thinking about ensuring consistency and working on efficiency. So do people who build centralised databases, but hey.

So if you regret signing a contract in this fancy supply chain blockchain, you can just choose a new fork to support, one without this contract?

No. Consensus mechanisms usually make this prohibitively expensive to do, even in the short term.

I'm don't follow, sorry. Are the hard forks not a big problem and you can easily choose which fork to support, or is doing so in fact prohibitively expensive to do?

Because as far as I can remember from cryptocurrency scene the former was certainly true, people were more than willing to settle on opposing camps over ideology. Would be a shame if that happened on a super serious business-application blockchain over some departmental or organisational kerfuffle.

Because that policy has to be enforced in an immutable, attributable way by a group of actors that don't trust each other.

You know what, we're going in circles. I try to get to the bottom of why something blockchain related can't be done with traditional systems, you respond with another buzzword that's still nothing that can't be done in traditional systems, and the cycle continues. It's mildly frustrating.

I guess the only way to do this is to wait until this is actually implemented somewhere and then compare how these supposed advantages actually pan out in practice. I expect costly mistakes in that field, but at least they'll be costly mistakes other companies can learn from and avoid.

Surprise, if you are actually designing a massive system, this kind of design requirements come naturally.

You are so close. The natural design limit of this massive database/computational system with common standards where no single actor has control, is a blockchain.

Oh, you're so close. People have been building these kind of systems successfully for decades. Now blockchain proponents are showing up and saying "hey, we have a new solution", and it turns out it's just the old solution again.

Your problem is that you think you have something new here. It's not. Blockchain is just a slow distributed database. It's one solution for a specific niche use case most systems designers don't run into, and if they do, they have other solutions that almost certainly work better depending on what they want to accomplish.

There's nothing "natural" about ending up with a blockchain. All you can argue is that it's natural to end up using cryptographic tools. Because they're tried and true solutions with decades of work based on them, just like all other business system blocks used in traditional systems. They're not manifestations of divine ideals whose time has finally come, or somesuch.

[Hit comment size limit, continued in another reply]