Actually, Git is technically a blockchain.

Commit hashes are a hash of the previous commit hash + new data. The structure (history) is replicated in a decentralized way on every user's node. The only missing thing is a proof-of-work, but that is optional in the definition of a blockchain.

> Actually, Git is technically a blockchain.

No.

You can say that git reduces to a Merkle tree. And blockchains use Merkle trees.

But you can't say that git is a blockchain.

https://gist.github.com/joepie91/e49d2bdc9dfec4adc9da8a8434f...

https://paragonie.com/blog/2017/07/chronicle-will-make-you-q...

I would argue the Merkle tree (or any other recursive signature algorithm) is the most important quality of a blockchain. To say that git is technically a blockchain is not entirely inaccurate IMO.

I think you are looking for the other qualities that typically apply to a blockchain such as the implicit need to "mine" its resources. Git simply produces these resources incidentally. I think this is the only major difference.

> I would argue the Merkle tree (or any other recursive signature algorithm)

A Merkle tree is not a recursive signature algorithm, because a hash function is not a signature algorithm.

https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass...

(Yes, you can build signature algorithms out of hash functions, but definitions matter.)

It's still missing important pieces. They both fall under the superset of "hash chain" / Merkle tree, but cryptocurrency blockchains are designed to deal with the possibility of bad actors. Git can't ensure trust, unless you PGP sign commits.

Git + PGP + some computationally expensive mechanism to broadcast verified PGP key attributions + a consensus algorithm might be a little bit like a blockchain, but I can't think of a good use case for that. Git repos generally aren't intended to be pushed to by the whole world.

A blockchain doesn't ensure trust either. The blockchain "trusts" whoever has the most powerful hash cracking array.

I should've said "attempt to ensure trust".

Incidentally, this is a problem I've worked on previously.

https://github.com/paragonie/libgossamer/tree/master/docs

The most important part of a block chain is its consensus mechanism. The merkle tree is relatively trivial.

There's significant difference in opinion of what part of the Bitcoin protocol is the "blockchain". Usually, people talk about the persistent stuff being the blockchain. In that case, bits sitting in storage don't implement a protocol, therefore don't have a consensus mechanism.

In other words, the blockchain is just the data structure, the consensus sits outside of that as a distributed protocol.

Of course, parts of that data structure enable the protocol to work, which is the most interesting property of the blockchain, but that's just blocks, merkle trees, and chained signatures.

If you're focusing on the construction of the term "blockchain", you're already lost. The name is a red herring. It's very clear that the innovative aspect of the technology, the part that enabled all the interesting applications, is the protocol layered on top of the merkle tree. That's the part that needed a new name, and deserved a better one than it got.

I know Git and Blockchains are said to be examples for (usage of) Merkle trees, but I fail to see how they're actually (using) a merkle tree.

Using the hash of a parent node as input to a nodes hash alongside the nodes data creates a link, but it doesn't create a merkle tree. In a Merkle tree the parent node is the hash of the hashes of its child nodes and only leafes have data. These are entirely different definitions and also serve completely different purposes (linking to a parent node vs efficient lookup of membership of some data in a larger dataset).

Could someone clear up my confusion and explain to me where Git/Blockchain use a Merkle tree in their fundamental functionality? Or is the term Merkle tree simply misreferenced a lot?

See https://news.ycombinator.com/item?id=9437021

in bitcoin the transactions are the leaves

Could you please elaborate how that ends up as a Merkle tree?

In a merkle tree the leaves are not linked and they have a tree structure of parent hashes on top. Git and Blockchain nodes are linked and the fundamental architecture doesn't need a tree structure of hashes on top. While this tree structure on top might be useful, it would be an optimization, but not part of the fundamental architecture. Again, what am I missing?

This might be complicated by the fact that "merkle trees" and git/blockchain invert the parent/child relationship. The root of the git/blockchain trees changes every time a commit/block is added, and the child nodes are called "parent commits" in git. Also the shape isn't going to have a wide base or be balanced like a binary search tree or similar.

When you say that "git and blockchain nodes are linked", I think you might be not abstracting the concepts from the form the data usually takes. For instance in git you might be thinking of a commit as a single package with all its source changes, headers, parent details and hash, but it terms of it being a merkle tree the leaf node would be non-hash parts (source code, non-hash headers etc) and the "tree on top" would be the hashes. This tree structure of hashes are absolutely part of the fundamental architecture of git/blockchain.

If Git is a blockchain, the. ZFS is a blockchain too.

Don't tell Oracle

Although Git also uses a chain of hashes, just like a blockchain, I'm not sure using this definition of blockchain (i.e. optional consensus protocol) is very useful, because then we need another word for the kind of thing that Bitcoin is. (On the other hand, perhaps the uselessness of the definition suits the uselessness of the concept itself.)

If Git is like using a hammer to hammer nails, blockchain (with consensus protocol) enables you to write without a pen by using the hammer to hit your thumb until it bleeds. And Wikipedia already has a pen that works.

> I'm not sure using this definition of blockchain (i.e. optional consensus protocol) is very useful

Honestly, "blockchain" as a word feels ill-defined and badly understood at the best of times. You could argue that "blockchain" deconstructs to nothing more than a "chain" of "blocks". What "blocks" actually are is up to the imagination, proof-of-work or other algorithms aside.

I get frustrated when people hail "blockchains" as the solution to everything because the term is so vague in everyday use that it's effectively meaningless.

I always thought it was clear: it was the combination of Merkle chains with a proof of investment (work, stake, etc), since that combination was the real novelty, worthy of a new name. It was quite confusing to see people calling "blockchain" to one of the pre-existing concepts. It's like calling any wheel a "bicycle".

Hashlinked, content-addressed, etc.

Well the commits are proof-of-work; though the validation is done by human (assuming the user doesn't have commit access on the main branch)

However its more of a Merkle tree https://en.wikipedia.org/wiki/Merkle_tree; which blockchain is also.

Proof of work is just some mechanism for a 3rd party to verify you actually invested “value” into the chain. That’s a PR.

Are there any traditional block chains where the proof of work is actually an investment into the chain? Such that the structure of the chain represents something of actual value (not a series of rare hashes), and additions to the chain add to that value? A la git. One potential example would be neural networks on a chain, where the work is training the network, and the value is intrinsic in the well-fitted resultant model.

Saito (saito.tech) pays for routing work rather than hashing work. Requires solution to 50 percent attack but means that all fees pay for the work of running the network rather than unrelated activities like hashing or staking.

There is one in industrial protocols for functional safety. It is called Ethercat Safety.

No, it’s not. The two technologies solve two different problems.

A blockchain is basically a single, global Git repository, where each commit is a “block” and the data inside that block/“commit” are transactions.

The defining difference between Git and a blockchain is that blockchains define which branch (commit history) is the correct one — the branch that you should put your commit on top of.

Blockchain provides a means to arrive at a consensus on which commit history (branch) is correct, while Git does not.

There are no blocks, just bare commits.

There is no chain, it's a DAG.

Off topic but it is considered difficult for NLP models to do sarcasm detection (because it’s a really hard problem, no widely available datasets, some context awareness is required, etc.)

For better or worse, in the last few years we have been generating a dataset on social forums by using “/s” at the end of sarcastic statements.

I’ll try and mine the “/s” statements on HN at least and see if I get somewhere.

That's going to be a great data set! Most people who use "/s" are great at sarcasm.

There is some prior art for this https://arxiv.org/abs/1704.05579

Humans have problems detecting written sarcasm. Not surprising that NLP models struggle with it too.

It's difficult because even if you have the context, the original poster can change classification after being called out by replying "oh, I was just kidding/I was being sarcastic". The same comment may and may not be sarcastic at the same time, Schrödinger's cat style.

That being said, it's an interesting problem. Hope you find something good.

> making Git commits work on the bitcoin blockchain

What does this even mean?

That every Git commit would take few hours and cost you transaction fee in Bitcoins.

At least you have a good excuse to abandon your pet open source projects

On the plus side, the whole world gets to reject your terrible commits?

The lights would go out in a few weeks.

"Blockchain Wikipedia" exists and the co-founder of Wikipedia, Larry Sanger, was involved for a while. It's called Everipedia and it uses the EOS blockchain: https://en.wikipedia.org/wiki/Everipedia

> 'Blockchain Wikipedia'

I mean, isn't this basically just Hugo and IPFS behind a Brand?

Yes, but much slower and more expensive.

You forgot environmentally damaging.

I think we should read about blockchains and understand it first. Then only we can actually decide whether it can actually be helpful for a particular problem.

A general rule of thumb is: Don't use blockchain if a database maintained by a single organization (person / company / government ) is sufficient. If multiple people interact, or multiple organizations interact and together want to maintain some data where they all collaborate and take decisions on how the data is changed then only we need blockchain.

So when I think about it, wiki can definitely be helped by blockchains.

Wikipedia does have a database that is in its sole control though. The fact that people outside the organisation interact with that database (as is the case in most uses of databases) is irrelevant; the interaction is controlled and mediated by Wikipedia.

No. "Multiple entities interact" may be a necessary condition for using a blockchain, but it's certainly far from a sufficient condition.

Yes, only when they cannot trust each other.

Agreed. The sufficient condition is you cannot blindly trust all those entities.

That's still far from sufficient.

Existing businesses have coped with that for hundreds of years.

You can have joint-ventures, where all participants send emissaries to, you can negotiate rights to view the books or other ways to create transparency. You can have contracts, backed by a legal system and state courts.

You can do many things. Blockchains are only one of those possibilities.

Most important question when somebody tries to sell you a blockchain: "What's the traditional way to do it?"

Correct answer: "People usually do X, but our blockchain proposal has advantages Y and Z."

Incorrect answer: "Nobody has ever solved that problem before!"