Comment by MayeulC | Hacker News Reader

Comment by MayeulC | Hacker News Reader

I partly disagree with the author, but glancing at other articles of the same blog, it seems that nuance is often left out.

On technical merits, the first point is kind of invalid. You can't rewrite history in git without changing commit IDs. And the two others are the same point: git doesn't have a distributed consesus mechanism.

It would be very easy to build one, though, which gets git close enough for comparison purposes. And the "blockchain" term only hints at the merkle tree aspect.

Now, on rebranding: while I feel the comparison apt, it shouldn't be used as a successfull example of blockchain technology. It can to an extent, but blockchain means something different in people's mind. I'd still do the comparison while pointing out the difference.

And that's something I often do, when explaining how either works.

And to me, blockchain (including consensus) is still a mathematical curiosity that hasn't proven useful yet. I've seen some interesting PoW proposals, like mail anti-spam, or rate limiting/captcha.

> git doesn't have a distributed consesus mechanism

It doesn't have an automated distributed consensus mechanism.

It does have a manual distributed consensus mechanism; that's basically how every popular open source project works. You fork the project, make a change, and if your commit is an improvement over the project you forked people will be inclined to merge it into their repositories, eventually arriving at a consensus.

In practice this process is often more centralized than distributed, but it doesn't have to be. If you want to 51% attack a popular repo, all you have to do is make constant, quality improvements to the project over time, and eventually your fork may well become the dominant one even over the objections of any centralized authorities.

The argument that git can have consensus if people just agree to isn’t compelling in this context. The distinction here is that with blockchain, consensus is mandatory and has a specific technical meaning. With git, consensus is optional at best, achieved only manually, is easily broken by rogue activity, and the word consensus might not even mean the same thing and can change over time in the case of git - there are lots of examples of original projects or forks that have claimed to be the one and only place people should concentrate their efforts, only to get abandoned in favor of something else later.

> You can't rewrite history in git without changing commit IDs.

But "not changing commit IDs" isn't part of git's utility. Not inherently.

This is easily proven by the fact that people do rewrite history. Because it's a useful feature to have.

To say that you can't rewrite history without changing commit IDs is like saying you can't prove a certain point without using the letter 'e'. Like… why are you even bringing up such a restriction?

> but blockchain means something different in people's mind

Right. Blockchain means "distributed ledger", which git is not. To say that git is one too is a technicality on the level of saying it's "wrong" to say "have your cake and eat it too", when it's actually "eat your cake and have it too".

It's not wrong, just not meaningful.

The only reason, in my opinion, to talk about the similarities between "blockchain" and git is to do exactly what this article does: to remove confusion in the mind of the listener that they are in any way meaningfully similar.

> I've seen some interesting PoW proposals, like mail anti-spam, or rate limiting/captcha.

Maybe in the future you'll mine the next cryptocurrency by proof of work in the form of "help this self-driving car that's stuck at an intersection it doesn't understand".

> But "not changing commit IDs" isn't part of git's utility.

How is that not a useful, intentional feature of git? Commit IDs (hashes) ensure DAG consistency as well as many other benefits. Linus explains it better than I could[0].

> This is easily proven by the fact that people do rewrite history. Because it's a useful feature to have.

It depends on the context. Try to rewrite commits in a PR for any public repo and see whether others agree it's a useful feature.

Anyway, I think you're proving the counter point: this is a shared feature of git and block chains - you know when history has been rewritten because the hashes changed.

[0] http://www.youtube.com/watch?v=4XpnKHJAok8&t=56m16s

Sure, it's a hiccup to rewrite history. But in Bitcoin it's 100% fundamental breakage. There's a difference.

I think you didn't take the parent's suggestion to make a PR seriously enough.

It is closer than you seem to think: rewriting history in a public, published repository will wreak havoc across contributors'clones. Contributors will have to contact upstream and ask if there was a reason, if it was intentional, or a malicious event. Especially if the root commit was changed, in which case you can't even attempt to merge repositories.

I don't really see why you couldn't backtrack the bitcoin blockchain, pretend an arbitrary block is the most recent one, and start your fork from there. The difference is,is that if you want to include some subsequent blocks, you will have to provide some proofs of work.

In both cases, some convincing is needed to move the consensus base to a new one.

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

In the important note:

> One of the cardinal rules of Git is that, since so much work is local within your clone, you have a great deal of freedom to rewrite your history locally. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. In short, you should avoid pushing your work until you’re happy with it and ready to share it with the rest of the world.

Also:

> it can rewrite huge swaths of your history, so you probably shouldn’t use it unless your project isn’t yet public and other people haven’t based work off the commits you’re about to rewrite

This is git 101. People can still choose to follow your rewritten history fork though, and it's also the case for bitcoin.

I replied to most things here in https://news.ycombinator.com/item?id=32443447

In git it's a hiccup if upstream does it. But it does work. For buttcoin you get the DAO split.

It’s important for audit ability and security that people can’t change commit ids from under you. If you run a security review of commit A and decide it’s safe to automatically deploy on your production systems, you’re only doing that because you know commit A can’t be changed.

Yes, it's a hiccup. But not fundamental because it is actually possible to do it.

A company can have a flag day, and keep a mapping of old hash to new hash for audit purposes.

I'm not saying do it willy nilly, but repos are fundamentally below the humans and any needs they have. Blockchains say code is law, and a fork (see eth DAO) is a complete clusterfuck.

Scrubbing some PII you legally need to remove from the corp codebase? Some poking, yes, but not a disaster.

Whereas they say there's plenty of child porn in the bitcoin Blockchain.

Reply on news.ycombinator.com