I have been asked several times this year about forks. This is probably because we have seen several of them during 2017 on the bitcoin blockchain, I enumerate from memory: Bitcoin Cash, Bitcoin Gold, Segwit and others that are happening as I write these lines. You can get a more comprehensive list here [i] and here [ii]. What is exactly a fork, what do these forks mean, where do they come from, how come I get new coins out of nowhere? These are the type of questions that this article is trying to answer.

The consensus rules

One of the bitcoin characteristics that are more difficult for newcomers to get into terms with is the answer to “who creates new bitcoins”. You can talk about several computer programs running in parallel and that rush towards the resolution of a puzzle. The one that finds first the solution, gets rewarded with a specific number of bitcoins that get written into the blockchain. Then typically the following questions are “who decides which puzzle to solve?” or “who decides how many bitcoins does the winner get?” Well the answer to all these questions is that “These are the consensus rules today”.

These are normal question coming from people like us who have lived all their lives in the “fiat world”, where the decisions about how much money is printed, and who can print it, are taken by governments and central bank authorities. In other words, by “someone else” and we simply accept the results as facts. Ironically, most likely the decisions about monetary policy are probably also taken via some sort of consensus amongst experts. But unless you sit in the Governing Council of the European Central Bank or equivalent, the decisions seem to come from a “central authority”.

In bitcoin world, decisions are taken differently. We can say that,

• a group of developers [iii] have gathered to maintain a program that implements a set of agreed rules aimed at creating a shared chain of blocks that contains information and information exchange, and that
• a group of individuals have agreed to run this program in their computers to maintain the chain of blocks and the information it contains and
• a group of people have decided to use that blockchain to transact information units contained in that blockchain.

As you see there is a lot of “agree” here and, in that sense, anybody can go and join the group of developers to influence the set of agreed rules. Or you can join the group of people that run bitcoin nodes and decide to run it, in any of the different versions available. Or you can go and transact on any of the different blockchains available.

It may seem that a group of contributors might not be very different to a group of members on the executive board of a Central Bank, but in fact it is quite different. Amongst the many differences, the most important one lies in the fact that you are not forced by law to abide by the rules of bitcoin. You can opt out of bitcoin and live your live happily without it. You will not be required to pay taxes to sustain the Bitcoin Core development team. If you don’t like the direction it takes, just drop – or sell – your coins and be with it.

The second main difference is that you can really be part of it. Rather than abiding by some other people consensual rules, you can get involved and contribute with your point of view, maybe even help to change the rules.

Changing the rules

Let us then assume that the community around bitcoin has reached to an agreement with regards to the rules under which bitcoin is going to exist. So, what about if you got involved and proposed a change in the consensus rules? Well, this is where things get interesting. What type of change are we talking about? As Antonopoulos mentions in his book [iv], bitcoin is a mix of different elements

• A decentralized peer-to-peer protocol
• A public transaction ledger (the blockchain)
• A set of rules for independent transaction validation and currency issuance (consensus rules)
• A mechanism for reaching global decentralized consensus on the valid blockchain (Proof-of-Work algorithm)

Changes can apply to any of these domains [v] . Then, what happens if we implement a change in the rules? Well, it depends on the specific change you are proposing and its effects on bitcoin. It also depends on how the change is implemented. And on who implements the changes.  And potentially on other aspects. Since the discussion is going to be lengthy and complex, let us start from the ground up and let’s remember how does bitcoin look like.

A chain of blocks

The blockchain is, well, a chain of blocks. Since the initial block – the genesis block [vi]– that started bitcoin on the 9 of January 2009, every subsequent block

• Is a solution to the puzzle proposed on the previous block
• Contains a “coinbase transaction” where new bitcoins are generated
• Contains several transactions of existing bitcoins, recorded as double-entry transactions between inputs and outputs
• Points to the previous block (this is how the chain is built)

If we simplify the diagram

Unplanned temporary blockchain split

As we have mentioned, in bitcoin several computer programs run in parallel and that rush towards the resolution of a puzzle. The one that finds the solution first has already included his reward (with a specific number of bitcoins) that got written into the block that gets added to the blockchain. As soon as one “solution” (new block) is found, the nodes get notified – they are interconnected in a partially meshed network – and start working on next puzzle, that will contain a set of fresh transactions, a coinbase transaction that will award them a specific amount of bitcoins and a pointer to the previously found block.

If two or more nodes find the solution simultaneously, the meshed network of bitcoin nodes might split into subnetworks, each of them working on top of the block they found, or the block they received first. This represents a split of the chain, where the latest block height contains two or more alternatives, and subgroups of nodes work on adding new blocks on top of each alternative.

With time, one of groups of nodes finds the following block faster than the others, and all node re-converge on the longest chain

This type of split is the inevitable result of the competitive race for creating new blocks. The first one that discovers the solution get the rewards, but if the arrival to the finish is too tight to decide who was the winner, a second – or third or fourth – run is going to be needed. In the long term we will get a clear finish and the chain will re-converge.

We personally do not call this occurrence a “bitcoin fork” but a temporary chain split, but we wanted to mention it for completeness.

What is a “fork” then, and what does it look like?

We will call a “fork” a change in the ruleset that applies to blockchain in the sense that bitcoin is and behaves differently from before the changes. There is no consensus on how big the change must be to consider it a fork, rather than an upgrade of the customer. It may result in a blockchain split in two branches but not necessarily.

In any case a bitcoin fork is not the result of the inherently random process of try-and-error for a block header hash, as we presented earlier in the case of the temporary chain split, but the result of a conscious decision to change the ruleset. A fork happens when a consensus emerges for a new set of rules and a change is proposed in one or several of the previous set of consensual rules. It may be a change in the maximum size of the block, a change on the scripted programming language that is used to validate the transactions, or just about anything else. These new rules force a change in the way the nodes behave, in the blockchain, or in both.

What happens then? Well, as we said before, it depends. It depends on

• what changes exactly
• who applies the changes,
• when do the changes apply

other aspects could be investigated (i.e. where are the changes applied for example). The scope of this article will be the three first bullets of the above list

Common Characteristics of forks

All types of forks have a set of characteristics that apply to all of them. We will mention them here so that we don’t have to mention them for every type of fork. Also, if a “fork” is missing any of these characteristics, then it is not a “valid” fork.

Forks will maintain the validity of already mined transactions and blocks

Forks can change the consensus rules in the sense that the blocks generated with the old consensus rules would not valid any more. However, this will only apply to newly generated blocks, or in other words, to blocks generated after the fork happens. Blocks generated before the fork will be considered valid, even if the new consensus rule set applied to them would consider them invalid. This might look like an incoherence but it has a purpose: the new consensus rules will only apply after the consensus has changed but it will respect the blocks generated with the old consensus up to before the fork. It is as if, for the new year, we decide to stop buying fiction books and we start buying only non-fiction books. Our library has started to change. However, we do keep our existing fiction books, we are not starting from scratch

In a few words, it is expected that all blocks and transactions mined before the application of the new ruleset remain valid. If the new ruleset rejects the validity of blocks existing before the fork (if we go and burn all our fiction books that we bought before the new year non-fiction resolution) we are not seeing a change in bitcoin or a fork, but the appearance of a new blockchain (or a new library).

Forks are contentious changes

According to this reference [vii], by the end of 2017 there were 11k+ full nodes on the bitcoin network. It is highly unlikely that all of them are going to agree on implementing the changes so typically some nodes will implement the changes while some other will not. This is what we call a “contentious change”.

On the other hand, if there is complete agreement about the changes, they are implemented at some point of the chain and bitcoin life continues. You can imagine that with 11 thousand + running nodes it is almost impossible that all of them agree and apply the changes so practically we will never get 100% adherence. However, beyond a consensually large amount of percentage adhesion, the change could be considered non-contentious. In non-contentious changes there is no chain split, as “all” the nodes switch to a new set of rules at some point. The blockchain starts recording the changes at this point – if the new rules have an impact on the information recorded on the chain of course – but remains a unique chain. Bitcoin has simply changed and everybody agreed. Well, names may not be important, but we should have a term to identify this occurrence. We will name it “non-contentious change” but not a fork.

In summary, this article deals with “contentious forks that respect the validity of the blocks prior to the change” or changes in the consensual rules of bitcoin where not everybody agrees on the change but the previous blocks and transactions are honored. Let’s see how to identify them and classify them to better understand their consequences.

A word on bitcoin change taxonomy

Classification of bitcoin changes is a difficult matter, as bitcoin contains a large set of characteristics and parameters, so many things can change. Which should be the criteria to classify changes?

In my opinion the purpose of classification is to allow us better to understand the nature of the changes and – most important – the consequences they bring to bitcoin. The link between “what are the nature of features” “what are the nature of changes on these features” and “what do these changes imply to bitcoin” is better mapped by analyzing the compatibility of the feature that changes. We need to classify features in a way that

• allows us to classify its changes by how compatible are between old rules and new rules,
• allows us to make a direct association between feature types, its changes, and the effect on bitcoin.

What types of features there are and how can they change?

In that sense I will classify bitcoin features in three categories

• Compulsory: Something that must be present in transactions or blocks for them to be included into the blockchain
• Forbidden: Something that must be absent in transactions or blocks for them to be included into the blockchain
• Optional: Something that may or may not be present in transactions and blocks. Its presence or absence does not represent a criterion to accept or reject transactions or blocks into the blockchain.

You can associate the Compulsory feature to the “MUST” statement in standards, the Forbidden feature to the “MUST NOT” and the Optional feature as the “MIGHT” or “MAY”.

With that classification of features in mind I will classify the changes as follows: do they change a feature classification? In other words, do they change a feature from forbidden to compulsory? From optional to forbidden? How many options are there?

For a specific feature that changes we will call

• Node_Old as the bitcoin node that does not upgrade the rules for this feature and applies the old consensus ruleset
• Node_New as the bitcoin node that does upgrade the rules for this feature and applies the new consensus ruleset

We can draw a simple table and we will see that there are nine options

• From Compulsory (in the old rules) to also Compulsory, Forbidden or Optional (in the new rules)
• From Forbidden (in the old rules) to also Compulsory, Forbidden or Optional (in the new rules)
• From Optional (in the old rules) to also Compulsory, Forbidden or Optional (in the new rules)

We have already classified the features and documented the possible transitions. What are the impact of each transition? Let’s discuss each case individually.

From Compulsory to Compulsory: Forks types 1a and 1b

How can a feature change from “Compulsory” to “Compulsory”, you might be asking? Well, it can change if the specific conditions are different in old nodes and new nodes. For example, say it was compulsory to include a minimum of 1000 transactions per block in the old rules. And the new rules might state for example that it is compulsory to include a minimum of, say, 2000 transactions. Both conditions are compulsory, and they refer about the same feature, but they are not the same.

We can distinguish two scenarios

• • • Type 1a: The requirement on the feature in the new rules is more restrictive than in the old rules (our previous example the new rule is more restrictive as it requires more transactions per block). We are then restricting capabilities on bitcoin. We will call this fork Type 1a. We can expect that “old rules” blocks mined by Node_Old that do not fulfill the more restrictive “new rules” condition will be rejected by Node_New
      • If Node_Old mining power is bigger than Node_New we will see a chain split as soon as Node_Old nodes mine a less restrictive block not fulfilling the more restrictive “new rules”. Node_New chain will grow on its own – rejecting that initial Node_Old less restrictive block and all subsequent blocks – but will not be able to force Node_Old chain to reconverge to Node_New chain as Node_New will not be able to catch-up with Node_Old blocks generation speed.

      

      • If Node_New mining power is bigger than Node_Old we will see the blockchain grow with new-style more restrictive blocks, but it will be constantly challenged by Node_Old attempts to grow its own chain by adding less restrictive blocks.

      

   

• • • Type 1b: The feature in the new rules is less restrictive than in the old rules. Say for example that in the old rules we required a minimum of 1000 transactions per block but the new rules only require a minimum of 500. The mirror of our previous example. We are then relaxing the conditions or adding capabilities on bitcoin. We will call this fork Type 1b. We can expect that “new rules” blocks mined by Node_New that do not fulfill the more restrictive “old rules” condition will be rejected by Node_Old .
      • If Node_Old mining power is bigger than Node_New we will see the blockchain grow with old-style (more restrictive) blocks, but it will be constantly challenged by Node_New attempts to grow its own chain by adding new rules less restrictive blocks

      

      • If Node_New mining power is bigger than Node_Old we will see a chain split as soon as Node_New mines a less restrictive block, as Node_Old chain will grow on its own more restrictive chain– rejecting the first Node_New less restrictive block and all subsequent after the fork – but will not be able to force Node_New to reconverge to Node_Old chain as Node_Old will not be able to catch-up with Node_New blocks generation speed.

      

   

From Forbidden To Compulsory: Forks type 2

If the characteristic was considered Forbidden by Node_Old and becomes Compulsory by Node_New then the new rules blocks will be totally incompatible with the new ones. Node_Old will reject Node_New mined blocks and vice versa. A chain split will happen.

From Optional To Compulsory: Forks type 3

If the characteristic was considered Optional by Node_Old then “old rules” blocks mined by Node_Old missing the characteristic will be refused by Node_New.

In these types of forks something Optional (or not even considered) under the old rules becomes Compulsory under the new rules. In this case the new rules are adding new compulsory functionality so we are restricting the acceptance criteria. Node_Old will not reject the blocks mined by Node_New, but Node_New might reject the blocks mined by Node_Old if they miss the feature in question.

• If Node_Old mining power is bigger than Node_New we will see a chain split as soon as Node_Old nodes mine a block missing the feature. Node_New chain will grow on its own – rejecting that initial Node_Old feature-missing block and all subsequent blocks – but will not be able to force Node_Old chain to reconverge to Node_New chain as Node_New will not be able to catch-up with Node_Old blocks generation speed.

• If Node_New mining power is bigger than Node_Old we will see the blockchain grow with new-style blocks, but it will be constantly challenged by Node_Old attempts to grow its own chain by adding old ruleset blocks where the feature is missing.

From Compulsory To Forbidden: Forks type 4

If the characteristic was considered Compulsory by Node_Old and becomes Forbidden by Node_New then the new rules blocks will be totally incompatible with the new ones. Node_Old will reject Node_New mined blocks and vice versa. A chain split will happen.

From Forbidden To Forbidden: Forks types 5a and 5b

By now you could guess what a “Forbidden to Forbidden” transition means. When a forbidden feature in bitcoins becomes forbidden but in a different measure. For example, from “old-rules” the maximum size of the block must not exceed 1MiByte to “new-rules” the maximum size of the block must not exceed 2MiByte. Or vice versa.

We can distinguish two scenarios

• • • Type 5a: The interdiction on the feature in the new rules is more restrictive than in the old rules. For example, if we were decreasing the maximum allowed block size from 1 MiByte to 500 KiBytes. We are then restricting capabilities on bitcoin. We will call this fork Type 5a. We can expect that “old rules” blocks mined by Node_Old that do not fulfill the more restrictive “new rules” condition will be rejected by Node_New
      • If Node_Old mining power is bigger than Node_New we will see a chain split as soon as Node_Old nodes mine a less restrictive block not fulfilling the more restrictive “new rules”. Node_New chain will grow on its own – rejecting that initial Node_Old less restrictive block and all subsequent blocks – but will not be able to force Node_Old chain to reconverge to Node_New chain as Node_New will not be able to catch-up with Node_Old blocks generation speed.

      

      • If Node_New mining power is bigger than Node_Old we will see the blockchain grow with new-style more restrictive blocks, but it will be constantly challenged by Node_Old attempts to grow its own chain by adding less restrictive blocks.

      

   

• • • Type 5b: The interdiction on the feature in the new rules is less restrictive than in the old rules. For example, if we were increasing the maximum allowed block size from 1 MiByte to 2 MiBytes. The mirror of our previous example. We are then relaxing the conditions or adding capabilities on bitcoin. We will call this fork Type 5b. We can expect that “new rules” blocks mined by Node_New that do not fulfill the more restrictive “old rules” condition will be rejected by Node_Old .
      • If Node_Old mining power is bigger than Node_New we will see the blockchain grow with old-style (more restrictive) blocks, but it will be constantly challenged by Node_New attempts to grow its own chain by adding new rules less restrictive blocks

      

      • If Node_New mining power is bigger than Node_Old we will see a chain split as soon as Node_New mines a less restrictive block, as Node_Old chain will grow on its own more restrictive chain– rejecting the first Node_New less restrictive block and all subsequent after the fork – but will not be able to force Node_New to reconverge to Node_Old chain as Node_Old will not be able to catch-up with Node_New blocks generation speed.

      

   

From Optional To Forbidden: Forks type 6

Something Optional (or not even considered) under the old rules becomes Forbidden under the new rules. In this case the new rules are forbidding a feature that was possible under the old rules, so we are removing functionality. Node_Old will not reject the blocks mined by Node_New, but Node_New might reject the blocks mined by Node_Old if they include the feature in question.

• If Node_Old mining power is bigger than Node_New we will see a chain split as soon as Node_Old nodes mine a block including the feature. Node_New chain will grow on its own – rejecting that initial Node_Old feature-including block and all subsequent blocks – but will not be able to force Node_Old chain to reconverge to Node_New chain as Node_New will not be able to catch-up with Node_Old blocks generation speed.

• If Node_New mining power is bigger than Node_Old we will see the blockchain grow with new-style blocks, but it will be constantly challenged by Node_Old attempts to grow its own chain by adding old ruleset blocks where the feature is included.

From Compulsory To Optional: Forks type 7

Something Compulsory under the old rules becomes Optional (or not even considered) under the new rules. In this case the new rules are removing functionality or relaxing the feature set. Node_New will not reject the blocks mined by Node_Old, but Node_Old might reject the blocks mined by Node_New if they miss the feature in question.

• If Node_Old mining power is bigger than Node_New we will see the blockchain grow with old-style blocks, but it will be constantly challenged by Node_New attempts to grow its own chain by adding new ruleset blocks without the feature

• If Node_New mining power is bigger than Node_Old we will see a chain split as soon as Node_New mines a block without the feature, as Node_Old chain will grow on its own – rejecting the first Node_New block missing the feature and all subsequent after the fork – but will not be able to force Node_New to reconverge to Node_Old chain as Node_Old will not be able to catch-up with Node_New blocks generation speed.

From Forbidden To Optional: Forks type 8

Something Forbidden under the old rules becomes Optional under the new rules. In this case the new rules are adding optional functionality. Bitcoin is becoming more permissive. Node_New will not reject the blocks mined by Node_Old, but Node_Old might reject the blocks mined by Node_New if they include the feature in question.

• If Node_Old mining power is bigger than Node_New we will see the blockchain grow with old-style blocks, but it will be constantly challenged by Node_New attempts to grow its own chain by adding new ruleset blocks including the feature

• If Node_New mining power is bigger than Node_Old we will see a chain split as soon as Node_New mines a block with the feature, as Node_Old chain will grow on its own – rejecting the first Node_New block including the feature and all subsequent after the fork – but will not be able to force Node_New to reconverge to Node_Old chain as Node_Old will not be able to catch-up with Node_New blocks generation speed.

Let us summarize what we have described

A word on hard forks and soft forks

We read continuously about “hard forks” and “soft forks”. Are they different from the types we have already defined? Or just a different way to name them?

In my opinion, the definitions we find on the internet about “hard forks” and “soft forks” are not unanimous, hence the terms should be avoided, or at least explained in their specifications and consequences.

For example, compare the definitions here [viii] it is mentioned that

“Hard forks is a permanent divergence in the block chain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.

Soft forks is a temporary divergence in the block chain caused by non-upgraded nodes not following new consensus rules”

Then here [ix]

“Softforks restrict block acceptance rules in comparison to earlier versions. New valid blocks are a subset of old valid blocks. The new rules allow a subset of the previous valid blocks, therefore all blocks considered valid by the newer version are also valid in the old version.

Hardforks ease block acceptance rules making previously invalid blocks valid in the new version. Obviously, this is not forward compatible as older versions will not accept the new blocks, causing the users of the old paradigm to remain on their own blockchain-fork indefinitely. To implement a hardfork, without a blockchain-fork, all users must switch to the new protocol consensually.”

In Antonopoulos [x] we find

“There is another scenario in which the network may diverge into following two chains: a change in the consensus rules. This type of fork is called a hard fork, because after the fork the network does not re-converge onto a single chain. Instead, the two chains evolve independently.

[…]

In practice a soft-fork is no fork at all. A soft fork is a forward-compatible change to the consensus rules that allows unupgraded clients to continue to operate in consensus with the new rules”

Finally, in BIP-009 [xi], Todd, Wuille, Maxwell and Russell very succinctly say

“backward-compatible changes (further called «soft forks»)”

This is too ambiguous in my opinion, although to be honest, they were not defining what a fork is.

As you can see there is no consensus (no pun intended) about what a “soft fork” and a “hard-fork” means. For example, I still see discussions where individuals do not agree if “soft forks” imply a chain split or not, even if they seem to agree that “softforks restrict block acceptance rules in comparison to earlier versions”.

Let me propose my own definition here based on the taxonomy we presented before

• Hard Forks: They would be the forks where the “old rules” blocks and the “new rules” blocks are incompatible with each other and the chain split is inevitable, independent on the mining power. These would be Fork Types 2 (Forbidden to Compulsory) and Forks Type 4 (Compulsory to Forbidden)

In all “Hard Forks” the chain split is inevitable

• Soft Forks are those forks where
  • New rules are more restrictive than old ones
  • New mined blocks are compatible with old rules
• These would be Forks Types 1a (Compulsory to Compulsory, restrictive subtype), Type 3 (Optional to Compulsory), Type 5a (Forbidden to Forbidden, restrictive subtype) and Type 6 (Optional to Forbidden)

In all “Soft Forks” there could be a chain split or not, depending on the mining power. If “new rules” nodes are not majority, the “old rules” nodes will maintain their own “old rules” chain. Otherwise, if “new rules” nodes have the bigger hash power, they will force the “old rules” nodes into their chain, even if challenged regularly.

Again, I am not big fan of the terms. I think that unless there is an agreement on what they mean, we should avoid using them. Use the terms at your own will anyway, just – like anything else – I recommend to know exactly what you are talking about.

When (and how) are the changes applied and BIP-009

For contentious changes – where there is not unanimous acceptance about the convenience of the changes – we have seen that depending on the type of feature that changes and the compatibility of the changes, several scenarios are possible. However, there are other types of possible disagreements beyond the “we don’t agree if the changes should be applied”. There can be differences in opinion about when and how the changes should be applied, that is, the process to follow to apply the changes. So even an initial non-contentious change (all agree on applying the changes) can become contentious if there is not agreement on how to proceed.

As it happens, there is an agreement on how and when apply the changes and it is described on BIP-009 [xii]. Having said that, this consensus could be challenged and we will enter a fresh new discussion on classifying the features on who and when they are applied, what happens when the how and then changes and the impact on the blockchain. This might end up in an additional article, however we will leave it for now and we will refer the reader to educate himself/herself by taking a look on what happened with SegWit activation, where several timelines where proposed.

Who applies the changes. User Activated Forks and Miner Activated Forks

There is also the possibility of a taxonomy on “who” applies the changes.

User Activated Forks

If the changes are applied by the end users – the ones generating the transactions – we call it a User Activated Fork. By “End Users” we mean here the different devices creating the transactions and sending them to the miners to be included in the blockchain. The End Users can change consensus on matters such as the types of signatures for transactions, format of the bitcoin addresses and the so. What End Users cannot influence are aspects such as the maximum size of the block, or if the new type of transaction will be included or rejected in new mined blocks (these are decided by bitcoin nodes).

All the precedent discussion applies here: End users can change Compulsory, Forbidden or Optional aspects of the transactions, so we would be discussing about the different types of changes mentioned earlier and different types of consequences.

I have also seen in many places mentions to “User Activated Soft Forks” (UASF for short) and “User Activated Hard Forks” (UAHF for short). Again, since there is no apparent consensus on what a “soft fork” and a “hard fork” means I prefer not to use the terms. It would be much preferable to specifically describe the change.

Miner Activated Forks

On the other hand, if the changes are applied by the miners – hence in the blocks containing the transactions, or in the bitcoin protocol that nodes talk – we would be talking about a Miner Activated Fork. Again, we see mentions to Miner Activated Soft Forks (MASF for short) or Miner Activated Hard Forks (MAHF for short). Same remarks as above.

Chain Splits and Replay Protection

In the case of forks that end up in a chain split, that is, changes in the consensus rules that force a chain split, there is an interesting case concerning compatibility of transactions generated by “old nodes” and transactions generated by “new nodes”. If both types of transactions are accepted by both blockchains – maybe because the chain split was motivated by a change in the block structure and not a change in the transaction format –  we might end up seeing that transactions that the users send to one blockchain might get exfiltrated and “replayed” in the other blockchain. For example, we could “spend” some bitcoins in one blockchain – by sending them to another address – and we would see them “spent” as well on the other blockchain on another block, maybe even a later one.

If the two forked blockchains represent different entities (different coins) this would not be advisable and we would need to implement some sort of “transaction replay protection” that prevents that transactions created and sent to one blockchain are accepted on the other blockchain.

The transaction replay protection can be made compulsory (Strong 2-way protection) or optional (Opt-in protection) for transactions, leaving the door open to forbid transaction replay or to leave the door open.

There are several schemas to implement Strong 2-way replay protection. For example, Bitcoin Cash achieved this through marking the signatures, which every transaction requires. This made transactions on their chain invalid on Bitcoin and vice-versa.

There are also several schemas to implement Opt-in protection. In the end all come to leave the door open to add some special marker in the transaction (such as putting a special string in OP_RETURN, making a magic nSequence value or ignoring transactions with certain version bits). Opt-In protections are less commonly seen as they can generate a big amount confusion in the users.

There is not much concern about “block replay protection”. Since the blocks are linked to the previous ones, there is no way a block from a blockchain can be “replayed” or inserted in a different blockchain.

Chain splits and Free Coins

And finally, a comment on why a chain split makes appear new coins out of the blue, or as it can be read on the Internet “free coins”.

When we see a chain split on some point of the chain, we see that the blockchain forms two different branches

In fact, what happens is that inside each node there is a copy of one of the branches. Old nodes will keep the common part of the blockchain plus the new blocks mined with the old rules.

New nodes will keep the common part of the blockchain plus the new blocks mined with the new rules.

As each node keeps a copy of the whole blockchain, each group of nodes will keep a copy of a different blockchain. Bitcoin will be divided into two groups of nodes: one group of nodes will grow one blockchain (with the old rules all along) and another group of nodes will grow another blockchain with old rules up to some point and new rules after that point. These different blockchains will have a common part – up to before the split – and a part where they are different. As a chain they are different, maintained by a different group of nodes and that’s why they typically receive different names. For example, “Bitcoin” for the one inserting “old rules” new blocks and “Bitcoin Cash” for the one inserting “new rules” new blocks. After the fork, we have two blockchains, hence two coins even if they share a common past. Effectively Bitcoin has been cloned into something slightly different while keeping the original flavor separated. Everything we had in the blockchain before the chain split will appear on the two blockchains. So, if we had bitcoins before the fork we see the same amount of new coins appear on the new blockchain. We are getting coins for free, yes.

This article was written by ignacio. You can contact him at admin@privatekeys.org

[i] https://en.wikipedia.org/wiki/List_of_Bitcoin_forks

[ii] https://howtotoken.com/explained/bitcoin-forks-chronology-ultimate-list-forks/

[iii] https://github.com/bitcoin/bitcoin/graphs/contributors

[iv] Andreas M. Antonopoulos “Mastering Bitcoin, 2nd Edition” ISBN – 978-1-491-95438-6

[v] For the blockchain and the transactions, the bitcoin protocol is the transport layer on top of which it exists. The bitcoin protocol exists to provide a reliable, decentralized, resilient and efficient layer on top of which bitcoin can exist. In that sense, the bitcoin protocol will not influence who many bitcoins do miners get, or how many bitcoins will ever exist. The bitcoin protocol is just a layer, and implements a communication network for bitcoin, but does not have a saying in the consensus rules. If the bitcoin protocol specifications change, it may cause a disruption in the transport layer of bitcoin. However, we usually see this more as a disfunction of the protocol, unless there is an explicit intention to split the bitcoin network. In a few words, there could be legitimate reasons to change the bitcoin protocol consensus and potentially this would result in disruption. However, this is unusual: people don’t seem to be religious (yet) about the transport layer of bitcoin. It is rather used as a mean rather than an end. Hence, we will not be talking much about the changes in the bitcoin protocol here.

[vi] https://blockchain.info/es/block-height/0

[vii] https://bitnodes.earn.com/

[viii] https://www.weusecoins.com/hard-fork-soft-fork-differences/

[ix] https://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork

[x] Andreas M. Antonopoulos “Mastering Bitcoin, 2nd Edition” ISBN – 978-1-491-95438-6

[xi] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

[xii] https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki