Hacker News Reader

Comment by dangero | Hacker News Reader

I've spent a lot of time doing consulting around blockchains for fortune 500 companies. Most technology choices are not a need. You can use MongoDB or MySQL in most cases. There are places where MongoDB has benefits, just as there are cases where a permissioned, immutable record has benefits. It's not a silver bullet, but it can add trust. This article seems to miss that creating immutable records of intermediary attestations can serve as an audit trail later. If these audit logs are 100% immutable, that's nice. It's more evolutionary than revolutionary, but it still has some value.

View on HN

The big problem with these kind of arguments is that is misses the interface between the real world and the blockchain.

Say I have a blockchain that tracks births and deaths. Now if I see a record on there I can be assured it hasn't been tampered with. But that tells me nothing about how it was created - was the person entering the data acting with malfeasance?

All blockchain does is audit the data after its creation. It doesn't solve the issue of provenance of the original information. This seems to be where all these schemes and ideas (beyond crypto-currencies[1]) fall down when compared to current databases.

[1]slow and pointless. Money transfer is solved and current systems, while lacking the assured fidelity of the transactional data, offer so much more - fraud detction, chargebacks, etc etc

That's why I said "intermediary attestations".

I did not miss the interface between real world and blockchain. I did not claim that the records would be 100% accurate. What I'm saying is, when audited and we discover that someone provided bad data, we know who that was.

That's how fraud claims work in general. Having a nicely packaged up list of who attested to what is nice. That's my point.

So we completely sidestep the difficult problem of ensuring truthful data in the first place but it's okay because we've got a really complex solution for replacing simple cryptographic signatures?

I'm not aware of any cryptographic system that provides immutable timestamps as strong as public blockchain timestamps, but I'd love to hear if I'm wrong.

As a sidenote, burdening blockchain with solving the "truthful data" goal is pretty unfair. In many cases this is an unsolvable problem.

HN commenters: “Blockchains are dumb! You could do the exact same thing with a distributed Byzantine fault tolerant database with publicly auditable merkelized logs that collects transactions into blocks!”

This criticism is valid but it's not a problem blockchain is trying to solve. It merely acts as a way to have immutable records. Regardless of if you use a blockchain solution or not, the fact that real world corruption or ignorance can lead to rogue data is an issue that exists in both cases.

The question is: does it make using blockchain pointless? I don't have the answer. The thing is, the only working blockchain use case - money - does not operate with real-world (non-reliable) data.

That's right! "Even though blockchain does not allow for modification of data, it cannot ensure such data is correct. The only exception is on-chain transactions, when the system does not need the real world, with all necessary information already being within the blockchain, thus allowing the system to verify data (e.g. that an address has enough funds to proceed with a transaction)."

However, I disagree that current money systems solve the problems solved by Bitcoin, but this is completely different discussion)

I agree! I don't consider audit use case here(mostly not to make the article too big, saving this example for further reasearch and publications), as well as many other "reducing trust" use cases. Do you have any example of such systems being implemented?

What's wrong with using a RDS instance running Postgres configured to be append-only and immutable?

It still leaves the possibility that the trusted third party operating that database (or Amazon) could modify the data. Blockchain would allow the same thing where that actor is malicious.

Though the real world problems we're solving rarely lack a trusted third party. And even when they do, a public log a la certificate transparency logs seems to solve the issue about as well in my eyes.

What allows that is multiple copies maintained by separate entities. If you have that, you don’t need a blockchain. If you don’t, a blockchain is just distracting from the problem.

Immutable data structure + GDPR right to correct or remove information = ?

(You can sort of get away with it if it's b2b only or a legal requirement to audit, but that limits the use cases further)

You can store hashes in the blockchain for auditing, you don't need to store the actual data.

So say my use case was birth certificate recording. As far as I understand in the US, there are a bunch of databases run by the states where state employees enter records. There are access controls in place that stop them from removing records. What exactly would "blockchain" solve in this case? And I don't mean theoretical problems.

GDPR doesn't automatically mean right to remove any information. Transactions required for legal reasons, ie money laundering prevention and purchase disputes, can (must) still be kept.

Reply on news.ycombinator.com