1. 14

  2. 5

    Betteridge’s law strikes again.

    One of the key features of a blockchain, which the author tries to handwave away, is that every link in the chain is verifiable, and unalterable. The author tries to claim that because each commit carries a reference to its parent, it’s a “chain of blocks”, but it’s not so much a chain as just an order. You can edit the history of a git repo easily, reparent, delete, squash, and perform many other operations that entirely modify the entire chain. It was kinda made that way.

    1. 12

      The technical properties of git’s and common block chain data structures are relatively similar.

      You can also fork a bitcoin block chain and pretend that your fork is the canonical one. The special bit about block chains is that there’s some mechanism for building agreement about the HEAD pointer. Among other things, there’s no designated mover of that pointer (as in a maintainer in a git-using project), but an algorithm that decides which among competing proposals to take.

      1. 16

        They are technically similar because both a blockchain and a git repo are examples of a merkle tree. As you point out though the real difference is in the consensus mechanism. Git’s consensus mechanism is purely social and mostly manual. Bitcoin’s consensus mechanism is proof of work and mostly automated.

        1. 2

          Please stop referring to “Proof of _” as a consensus mechanism. It is an anti-sybil mechanism, the consensus mechanism is called “longest chain” or “nakomoto consensus” - you can use a different anti-sybil mechanism with the same consensus mechanism (but you may lose some of the properties of bitcoin).

          The point is that there are various different combinations available of these two components and conflating them detracts from people’s ability to understand what is going on.

          1. 2

            You are right. I was mixing definitions there. Thanks for pointing it out. The main point still stands though. The primary distinction between a blockchain and git is the consensus mechanism and not the underlying merkle tree datastructure that they both share.

          2. 1

            Mandatory blockchain != bitcoin. Key industrial efforts listed in https://wiki.hyperledger.org/ are mostly not proof-of-work in any way (the proper term for this is permissioned blockchain, which is where industrial applications are going).

            1. 2

              You are correct. I don’t disagree at all. I used bitcoin as an example because it’s well known. There are lots of different blockchains with different types of consensus mechanisms.

        2. 2

          You can make a new history but it will always be distinct from the original one.

          I think what you’re really after is the fact that there is no one to witness that things like the author and the date of a commit are genuine – that is, it’s not just that I can edit the history, I can forge a history.

          1. 1

            what was all that hullabaloo about git moving away from SHA-1 due to vulnerabilities? why where they using a cryptographic hash function in the first place?

            what you said makes sense, but it seems to suggest this SHA-1 thing was a bit of bikeshedding or theater

            1. 2

              Because you can sign git commits and hash collisions ruins that.

              1. 1

                ah that makes some sense

              2. 2

                Git uses a cryptographic hash function because it wants to be able to assume that collisions never occur, and the cost of doing so isn’t too large. A collision was demonstrated in SHA-1 in 2017.

                1. 3

                  SHA-1 still prevents accidental collisions. Was Git really designed to be robust against bad actors?

                  1. 2


                    1. 1

                      The problem is that it was never properly defined what properties people expect from Git.

                      You can find pieces of the official Git documentation and public claims by Linus Torvalds that are seemingly in contradiction to each other. And the whole pgp signing part does not seem to be very well thought through.

                2. 1

                  Technically you haven’t really made the others disappear. They are all still there just not easily viewed without using reflog. All you are really doing is creating a new branch point and moving the branch pointer to the head of that new branch when you do those operations. But to the average user it appears that you have edited history.

                3. 1

                  If you have multiple forks, accepting random “commits”, which is the actual fork to follow ? Basically blockchain follows the latest fork with the first solved problem and all forks sync to it.