![DDD.jpg](https://steemitimages.com/DQmT77rKjNptVzQkBmNwuF1FDimpCGzUEXsXPxW5wR37GM2/DDD.jpg)

There has been much talk about the “Bitcoin fork” lately. So I thought it would be appropriate to explain some of technical stuff behind this obscure phrase. 

The word ‘fork’ in this context originates from open source software. Open source software is computer code, which is intended to be openly accessible and liberally used by anyone reading it. Open source software can be coded communally (such as with the GitHub platform), or alternatively can be copied locally and coded separately.

The development of software like this would allow to draw trees: each time the code was copied separately there would be a new branch. This would be called ‘forking’, since the same code would then develop in two parallel directions.

As we know, the Blockchain is decentralized, which by definition means there is no absolutely “correct” chain. Each node in the network downloads all the blocks to connect a chain, verifies them against the laws of math and Bitcoin and chooses the correct chain accordingly. For instance, if there is a block that has an invalid cryptographic signature, any chain including that block is invalid.

A block will also be invalid if there is a violation of the Bitcoin rules such as, for instance, if a miner rewards themselves with 26 coins instead of 25 as per protocol. Either way, it is up to the individual to verify the validity of the blockchain. Therefore, it seems, if there are two conflicting chains, one is valid and the other is malicious.

However, small forks happen in the blockchain naturally quite often. If two miners find a new block at the exact same second, they will both have valid and legitimate blocks, and neither will have a reason to toss it out. Both blocks are linked to the last one, but the block after will have to be linked to one of these two. Technically, this is a fork in the blockchain.

This happens every so often in the blockchain with no malintent. Miners tend to quickly converge on one chain and discard the other because of profit-related motives, and so these discarded chains are usually only one block long and are considered a statistical loss. While technically these are forks, they are short and not intentional, so they are referred to as “orphaned blocks”.

What we’re hearing in the news these days is a whole different beast.

There is a heated technical discussion on a significant issue for a few years: how Bitcoin deals with scalability and high load. Only recently has the discussion become a more broadly discussed matter, seeing as how nothing has been done and with all the growth lately, the blockchain has been under stress and experiencing delays and higher costs for transactions. The technical discussion is immense and interesting, and any summary will not do it justice.

In one sentence, the issue revolves around block size: currently limited to 1MB per block of transaction. A measure put in place years ago to prevent DOS attacks, but kicking the can down the road for how to scale Bitcoin and allow for more widespread use of the system.

The most interesting recent developments involved a few developers writing a new version of the Bitcoin software. The project named BitcoinXT is lead by Mike Hearn and Gavin Andresen, and it takes a practical stand on the issue, allowing for bigger blocks. This is not the first time a new version of the Bitcoin software is written, but it is the first time one is created with the intention of allowing the blockchain to fork.