[tscs37]

It's not a redefinition, it's a definition that has been around since the 1990's [0], the only requirement for a blockchain is A) directed linked list (block points to previous block) and B) cryptographic security (use hashes as block index)

Bitcoin is merely the first application to use Blockchain in a decentralized proof-of-work manner.

[jacquesm]

A git repository is a Merkle tree.

http://en.wikipedia.org/wiki/Merkle_tree

A bitcoin blockchain is also a Merlke tree.

But a git repository is not a blockchain.

[tscs37]

It is a blockchain is you don't merge since you have a commit pointing at a previous commit, (block points to block), merges point to two parents but Ethereum has that almost with uncle blocks.

The commit log of a repo is almost certainly a blockchain, which is why I mentioned "to some extend"

[jacquesm]

You are simply wrong.

Think of a blockchain as only one strand (say, the leftmost strand, from a leaf all the way to the root) of a Merkle tree. Think of a git repository as the whole tree. So no, they are not equivalent.

If they were there would never be a way to have more than one branch depend on a previous one.

[tscs37]

As mentioned, the git commit log, not the entire repo, which is more organized like a merkel tree, though that is only really the storage.

The commit log is a strict DAG, if you don't have any merges, it is a strict blockchain, otherwise it gets fuzzy but is close enough.

I never said it's equivalent but that is what a blockchain is; "A blockchain [...] is a continuously growing list of records [...] which are linked and secured using cryptography."[0]

This doesn't mention "Can't be a merkle tree" for one, but also doesn't mention "can't consist of branches which merge again" or "requires proof of work" or "must use signatures" (cryptography refers to the hashes normally but can refer to anything else too)

Git also acts like a blockchain, if you change the past (edit a past commit) you need to update all following commits for the new hash and their children hashes and anyone who has the repository must do a force pull, similarly to how Bitcoin rejects fork chains with less proof-of-work.

It might be worth mentioning that Bitcoin also uses MerkleTrees for storage as they are very good for quickly comparing sets.

A blockchain does not necessarily process financial transactions at all and I don't see why it must be a requirement.

[0]: https://en.wikipedia.org/wiki/Blockchain

[jacquesm]

"if you don't have any merges" -> so, not a blockchain.

What you are saying is that you can use git in such a way that you get something resembling a blockchain but - again, and it is getting tiresome - that does no imply equivalence between git and the blockchain.

I really don't understand why you keep arguing.

[tscs37]

As I mentioned, even with merges it still has the properties of a blockchain, just not the ones traditionally used by cryptocurrencies.

You still have blocks (commits) pointing to other blocks (commits). Some blocks just points to multiple other blocks (think the uncle system in ethereum, which is just exactly that; temporary forks that are still included into the chain)

[TheDong]

You didn't include the reference link. The term "blockchain", as used these days, refers to the distributed system underlying cryptocurrencies.

That's not a thing that has existed since the 90s nor is it a thing with so few requirements.

[tscs37]

The first paper on blockchains was published in January 1991 (revised/received in 1990) [0]

>The term "blockchain", as used these days, refers to the distributed system underlying cryptocurrencies.

That's how you prefer to use it but it doesn'T change how it's defined [1]

[0]: https://link.springer.com/article/10.1007/BF00196791

[1]: https://en.wikipedia.org/wiki/Blockchain

[sirclueless]

The common consensus for the term "blockchain" is not based on the 1991 paper, but on Bitcoin's use of similar technology to make a distributed ledger. The term itself is relatively recent, and was not used until well after Satoshi's paper. For example, Harvard Business Review describes it this way:

"At its most basic, blockchain is a vast, global distributed ledger or database running on millions of devices and open to anyone" [1]

That incorporates at least two concepts that are typically associated with the term "blockchain" that go beyond the basic cryptographic data structure: they are distributed, and they are open. Lots of technologies use a similar data structure; git uses a similar data structure. But when a silicon valley startup comes to you and pitches you on their "hot new blockchain tech" they probably don't mean git.

[1]: https://hbr.org/2016/05/the-impact-of-the-blockchain-goes-be...

[zaarn]

I have to agree with GP here.

>but on Bitcoin's use of similar technology to make a distributed ledger.

That doesn't really change a thing. Bitcoin merely uses a blockchain to ensure consensus, if all nodes are trusted then you don't need proof of work and you can switch to simply linking the list (see Git or Ethereum Testnets), and the contents of the blockchain are mostly irrelevant too (you can put anything on there, transactions are merely one type of thing you put in there)

At it's most basic, a blockchain is just a directed graph of nodes where a cryptographic method links two nodes together in a child-parent relationship. Everything else is just added fluff for the specific usecase.

[sirclueless]

I think a lot of people would disagree with you. There are obviously many methods besides proof-of-work to achieve consensus, but a blockchain cannot properly be called a "blockchain" unless there is some consensus protocol. Not every DAG of digital hashes is a blockchain.

Under your definition, every CBC mode stream cipher could be called a blockchain, which just makes the term meaningless. It was coined for a specific purpose: to describe how Bitcoin and related cryptocurrencies operate at a technical level, especially how they guarantee integrity and prevent double-spending.

[zaarn]

In git the consensus protocol is "whatever the maintainer thinks is the correct HEAD" or "what the maintainers can agree on to be 'master'". There are many ways you can achieve consensus.