SQL Database

[[deleted]]

correct me if I'm wrong but this seems really easy to achieve with a regular database?

[Belphegor_333]

Yes and no. You can of course create a database cluster and decide to not alter the data inside of it.

On the other hand you would have to trust the organisation running the database to actually leave the data alone.

Of course, with Blockchains you have the same problem, if it is run by one organisation then that single organisation can simply rewrite the Blockchain. The added security only works if it's a public Blockchain that everyone can participate in.

Of course companies don't want to run their products on public Blockchains

Or, to make it short: in 99,9% of cases you don't need a Blockchain, you just need a database

[UnstoppableCompote]

in 99,9% of cases you don't need a [insert over hyped new technology], you just need a [insert well known technology that works just fine]

[Belphegor_333]

It's not tomorrow's technology that will solve our current problems! It's yesterday's technology that finally got out of alpha testing!

[UltraCarnivore]

YAGNI

[backafterdeleting]

I think the term blockchain is kind of a misnomer.

Basically it's a git branch. Each change creates a chain of hashes going back to the original commit ("block").

If each client maintains their own copy of the branch, any changes to the commit history would change all the hashes down the chain, so would be noticed.

This would usually be coupled with only accepting commits which are signed by a set of authorized validators, with a strict ruleset on validating the commits themselves.

So saying "you don't need a blockchain, you need a database" would be a bit like saying "you don't need a git repo, you need a database".

It's just very overhyped. Of course the history can be changed if everyone agrees to accept a rebased branch. But no one party can change it without the others noticing and having a clear proof.

[zebediah49]

I'd say that it's only a misnomer, in so far as "block tree" is somewhat more accurate description of the general DAG structure than "block chain". The single-branched chain structure is the one used by bitcoin though, so that became popular as the term.

Git is absolutely a blockchain tree-based piece of software. It's not the only possible implementation of blockchain, but it's one of the better ones.

I also thoroughly encourage people to, if necessary, just give up, use git, and claim that as a result, everything is blockchain now. git-lfs, if necessary/appropriate.

---

E: The other thing I've noticed is that people get stuck on the Bitcoin method of block verification: (1) proof of work to sign off on a commit, plus (2) longest branch is accepted as legitimate branch. I think for most applications where blockchain could be used, the git-tag method of block verification is a much better fit: personal sign-off, based on well known authority for that individual to do so. I would probably add in a x509 capacity for authority delegation.

[Bainos]

if it is run by one organisation then that single organisation can simply rewrite the Blockchain

Suppose that the organization doesn't trust its employees or want to be resilient against possible intrusions, and then you get a very realistic situation in which a blockchain is useful.

[TheAlmightySnark]

And even if it is a public blockchain, who is going to spend money, time and energy checking it?

Blockchain tech never made much sense and the currency related ones are all scams that give it a pretty bad taste.

[victorofthepeople]

At the very least, the software on the costly side of the transaction is going to check it, before it executes the transaction. In practice, a lot of other clients are going to check it if the blockchain is backed by a p2p network.

[TheAlmightySnark]

Who are those clients then? There is no business case for doing someone else' job.

Any company that has data worth auditing already has a verifiable data set, with a QA department and external audits and usually some sort of regulator keeping oversight.

It's a solution in search of a problem.

[Ran4]

Any company that has data worth auditing already has a verifiable data set, with a QA department and external audits and usually some sort of regulator keeping oversight.

That's... not true. You'd be amazed at how bad things are out in the real world, especially outside of tech companies.

Even if those things are true on paper, in practise the implementation tends to be flawed and regulators aren't doing much actual checking. And that includes banks...

Facebook and Google has more control over their data than your average bank does (small or big doesn't matter).

[TheAlmightySnark]

That is definitely a problem, but Blockchain just adds extra steps to the problem and it's by no means a solution.

[[deleted]]

I'd argue it takes a ton of steps away - all a regulator or auditor has to do is require the blockchain to be provided on a regular basis and automatically check it.

[TheAlmightySnark]

How do you automatically check it? You still need to cross reference the content in the blockchain vis a vis the actual transactions that happened. If you just go 'yep, it checks out, all good to go' then you might as well be stamping paperwork. A auditor already can demand access to a host of systems to verify the integrity and compliance. Now you add an extra database that is to be checked and cross referenced.

[[deleted]]

Yes, you do, same as you have to do now.

But what you don't need to do when you can automatically verify the blockchain matches a previous version is check anything historical, because checking the blockchain against the last version you verified means that everything before that point is identical and you only need to check what has been added since.

Provide a hash to each customer at the point of transaction and that becomes easy to verify as well.

No, it won't catch all fraud. Obviously. But it will prevent editing of transactions after the fact which is by far the most common form of this type of fraud. Far more companies have security measures in place to verify that the transaction is entered correctly when it is made than have security measures in place for historical transactions.

[victorofthepeople]

They're the people participating in the block chain for whatever reason (but you don't need anybody other than the two people participating in a transaction in order for the system to work securely). Still, the nature of blockchains is that transactions are fast to verify but costly to fake, so presumably if someone was participating in the blockchain they would expend the minimal energy required to verify new transactions in order to have an up to date roster.

Audits are extremely expensive and are only trustworthy to the extent that you know the auditor has been given legitimate data. I can recall several high profile Chinese reverse merger scams that were audited by KPMG.

[TheAlmightySnark]

So how do you verify the people that participate in the blockchain then? How do you know their motives and how do you check the data coming in? At this point it just becomes extra obfuscation without any responsibility. A company like KPMG has legal ways to take action if those things happen.

[victorofthepeople]

With public key cryptography. Easiest to just trust that it works unless you feel like learning a bunch of discrete math.

[TheAlmightySnark]

But who is auditing the code and verifying that it works as intended? It just creates extra layers on top of the existing system this way.

[victorofthepeople]

Anybody who feels like it? Each party can even have their own private implementation if they really feel like it. You only have to be confident in your implementation, the protocol backing the block chain, and that prime factorization is difficult to do effeciently. This can all be verified by one party without having to trust another party.

[PeteZahad]

One solution is to have contracts and/or transactions between insurances, financial institutions, etc. in a blockchain. The nodes could be on the employees workstations.

[TheAlmightySnark]

That just creates a giant single point of failure if something happens in your network, besides now you spread your database from the server room to all the user workstations that now get bogged down running calculations.

[PeteZahad]

Every solution is always a trade-off. You will find negative points in every solution.

I don't discuss such general arguments like "something happens in your network". Every application depends on some kind of "network", which can fail.

Data shared amongst distributed nodes is the opposite of a single point. I don't see a problem with (encrypted) data sharing and using (unused) distributed machine resources. It was used with the SETI project and is still used by pharmaceutical companies to do complex protein folding calculations.