Hacker News Reader

Comment by stevesimmons | Hacker News Reader

But how does blockchain help here, compared with other ways of syncing data?

You'd be stupid to use, say, ETH to do it when you can simply have multiple parties sign and publish events in a distributed append-only log, which they keep syncronised. That doesn't need PoW or to be a currency.

Without the blockchain consensus mechanism, how else can you guarantee the log has only be appended?

With a hash chain[0], an idea from 1981.

[0] https://en.wikipedia.org/wiki/Hash_chain

I am interested in this and I have an emotional desire for you to be right; I'm skeptical of every application I've ever seen for blockchain.

That being said, it is not clear to me how a hash chain guarantees that the data it stores hasn't been modified.

Okay, maybe I should have posted the link to the Merkle tree page[0] instead.

The basic idea is, you have a chain of 'transactions' (like in bitcoin or think git commits) und you store the hash of the content + the hash of the member before as a checksum. This way, if you alter the log file, the hash for the modified entry is suddenly different, and the chain breaks, because the next member used your hash as input to calculate their checksum. So you can not only see that the file was tampered with, you can also say which entry was modified.

Edit: Merkle trees[0] generalize this concept into trees, which are e.g. used in ZFS (the file system), git and in the blockchain.

[0] https://en.wikipedia.org/wiki/Merkle_tree

It seems to me that if you have a copy of the information locally and compare it to the remote, you can see whether they diverged with or without a hash - the hash certainly makes it faster, but it's not clear to me that a hash chain or a Merkle tree offers a guarantee that's as powerful as the blockchain's promise.

(Social factors and forks to change our minds on blockchains notwithstanding)

Like git. The value isn't necessarily in that there can't be conflicts, but that conflicts are straightforward to surface and resolve.

How do you deal with multiple copies with different signing parties who claim to have the true copy?

Erm the entire point of having multiple parties sign is you get the quorum which is how you avoid this issue.

Sure, you have a limited number of participants and some tweaking to do on the quorum (in some cases you might want all parties to sign).

But hey - the blockchain cool-aid gang tried to sell it as a solution for COVID contact tracing. Which is beyond laughable. The entire industry is a shillfest.

Anti-Corruption tech. If everyone's scores are just stored in a SQL databse, people can pay off officials to change their grade, Ferris Bueller-style. Blockchain prevents any province or official from having superuser power over the data.

That would make sense if: - There weren't other methods to prevent tampering - Governments didn't want anti-corruption methods without having admin powers to exclude themselves.

This doesn't really make sense. We have SQL databases with permissions to prevent tampering, and audit logs, and myriad other solutions.

In addition, I don't see what prevents an "official" from writing a social credit transaction (disclaimer that I have no idea how China's "social credit" system works or even what it is) to the blockchain. Nodes validate to solve disagreements where one node says a transaction happened that did not. This does not appear to be the same type of dishonesty being referred to here.

You can achieve this in a SQL database with proper processes, auditing and controls.

The world has functioned up until the magical dawning of the blockchain.

The other ways require you to trust the operators of other nodes you sync with.

The only between-nodes trust blockchain relieves you of is trust in the history of a multiparty transaction log.

A blockchain doesn't prevent individual parties from lying about things only they would know about -- if that's what's on your chain, you still need trust.

Reply on news.ycombinator.com