> the idea that Git provides what a blockchain does.
Because Git is a Merkle DAG and blockchain is a Merkle chain. (I think that's the word)
So, although it would be ugly, you could store data in Git as a linear series of commits and get the same public or private ledger.
> whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions
But if your clients who don't trust you are monitoring the repo, and you do something like a `push --force`, they would see the hashes change.
> But we use a public blockchain for a reason.
I've tried to guess the reasons:
1. If the public ledger is watched by 100 other people, it's much harder to roll back an event than if it's only watched by a few clients who might not notice if you post an event and then immediately revoke it.
2. Since the public ledger gets a lot more traffic, its clock is more accurate. With a private ledger (Like the Git hack) you could still use the latest Bitcoin hash to prove "Commit B is made after Time A", but the window for "Commit B is made before Time C" is very large.
Honestly, my problem with blockchain is just the word "blockchain". I love public notarized ledgers. But I don't want to buy something that's riding off the hype of Bitcoin and buzzwords, and I don't want to sell that to people.
I need an audit log for something at work and I'm trying to figure out if this is useful. If it is, I would never tell my boss that someone called it blockchain. Non-programmers will think it's unbreakable Hollywood magic crypto.
As an addendum to the idea, perhaps have the git commits signed via a public timestamping server. (ie to say, any commits that do not have a corresponding timestamped signature will not be accepted).
As CT shows, there are other ways to solve the audit-logging-for-untrusted-parties problem.
With photographs it makes sense - A server that can tamper with photos live is not sci-fi, but it's also just a little bit expensive.
In my case I want to notarize text. What if I store "evil message" in my database and publish "good message" to the PNL?
Unless the end recipient of "evil message" is also logging to the PNL, (Which is hard, they're supposed to be a dumb client) nobody will ever contradict the server. I could round-trip the messages through the PNL. Make the recipient pull them from there instead of the server. But that sounds like extra risk.
It's a tricky problem, and in the end I'll have to cut lots of corners for convenience. That makes me sad.
Because Git is a Merkle DAG and blockchain is a Merkle chain. (I think that's the word)
So, although it would be ugly, you could store data in Git as a linear series of commits and get the same public or private ledger.
> whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions
But if your clients who don't trust you are monitoring the repo, and you do something like a `push --force`, they would see the hashes change.
> But we use a public blockchain for a reason.
I've tried to guess the reasons:
1. If the public ledger is watched by 100 other people, it's much harder to roll back an event than if it's only watched by a few clients who might not notice if you post an event and then immediately revoke it.
2. Since the public ledger gets a lot more traffic, its clock is more accurate. With a private ledger (Like the Git hack) you could still use the latest Bitcoin hash to prove "Commit B is made after Time A", but the window for "Commit B is made before Time C" is very large.
Honestly, my problem with blockchain is just the word "blockchain". I love public notarized ledgers. But I don't want to buy something that's riding off the hype of Bitcoin and buzzwords, and I don't want to sell that to people.
I need an audit log for something at work and I'm trying to figure out if this is useful. If it is, I would never tell my boss that someone called it blockchain. Non-programmers will think it's unbreakable Hollywood magic crypto.