Hacker News Reader

Comment by yokem55 | Hacker News Reader

This is true as long as you trust the issuer of the transparency log to not go back and re-write the history of the log. That's a trust assumption that most folks are fine with, but it should be explicitly be understood to be there.

A blockchain takes that trust assumption and spreads it out amongst the social consensus of the chain, so re-witing of history could only occur if there is a consensus to do so.

View on HN

Who is both internal enough to get a copy of your HR database but external enough that their logs can't be changed as easily as a non-blockchain system's?

Honestly, it might be possible to do this magic by having the third party issue a signing certificate based on a hash.

Send me a hash as new data is added to your DB and I cut you a cert... the next cert includes hash of the last cert plus the new hash you just gave me...

An external service that signs and dates [a hash of] your database is very viable! But at that point there's no longer a distributed ledger.

Isn't the whole idea of certificate transparency to detect that situation? That's why the system also has auditors which would detect such tampering.

CT doesn’t require anonymity: the trust in CT comes from the tamper-evident design creating a risk to your reputation if you cheat. Once you have third-party trust relationships you no longer benefit from the expensive blockchain mechanism designed to work without them.

The challenge is that if a discrepency is shown, how do you know who is lying? The whistleblowers or the CT log vendor? A consensus mechanism built on top of the log would be able to show the 'history of the history' to enable folks to make better determinations on who to trust or not.

The CT log vendor is signing entries, so although you don't know what the "true" state of the log is, you know that you cannot trust the CT log vendor.

Reply on news.ycombinator.com