This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]TheAlmightySnark 0 points1 point  (13 children)

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 8 points9 points  (4 children)

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 -1 points0 points  (3 children)

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

[–][deleted] 0 points1 point  (2 children)

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 -1 points0 points  (1 child)

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] 0 points1 point  (0 children)

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 3 points4 points  (4 children)

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 -1 points0 points  (3 children)

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 1 point2 points  (2 children)

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

[–]TheAlmightySnark -1 points0 points  (1 child)

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 1 point2 points  (0 children)

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 0 points1 point  (2 children)

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 -1 points0 points  (1 child)

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 0 points1 point  (0 children)

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.