<blockquote>
  <p>After a hard fork, what happens to the full nodes? Say 11,000 BTC full nodes existed prior to the fork. Do all 11,000 end up supporting both BCH and BTC? Or does BCH start building it's own network of nodes. Not asking about miners, just about full nodes (although, it will help if you can address the mining nodes as well).</p>
</blockquote>

<p>A hard fork means that a new set of consensus rules is being used which splits the blockchain into a blockchain following the old rules and a blockchain following the new rules. There is no "in between" for a node to follow both rules and nodes are not typically equipped to simultaneously support two blockchains.</p>

<p>In the event of a hard fork, the nodes which support the new rules and the hard fork's activation rules will separate from the nodes which do not support the new rules. They become their own network and have their own blockchain. This applies to all full nodes, which miners are a subset of.</p>

<p>So in your example, none of the nodes will support both BCH and BTC unless they were specifically designed to do so. The standard behavior (i.e. nodes using Bitcoin Core for BTC or Bitcoin ABC for BCH) is to only support one chain whose consensus rules are hard coded. Some of those 11,000 nodes will have the BCH rules so they will split from the other nodes which do not have the BCH nodes.</p>

<blockquote>
  <p>Also, in the softfork scenario, I believe the 11,000 nodes are divided - say 7000 support the softfork (e.g. Segwit) and the remaining 4000 do not. In that case, how do transactions remain legit between the supporters and non supporters. </p>
</blockquote>

<p>A soft fork is backwards compatible with old nodes. It must be designed in a way such that old nodes will not be kicked off of the network after the activation of the soft fork. So for soft forks, the soft fork was designed so that transactions under the new rules are also valid under the old rules. For segwit, this is done by stripping out the segwit specific components which are completely new so that non-segwit nodes are able to parse and validate the transactions.</p>

<p>In a soft fork, there is no chain split and all 11,000 nodes are still using BTC and following the same blockchain.</p>

CC BY-SA 4.0
2018-05-21T21:50:58.330Z
Thanks. That is super helpful. Followup On Hard Forks - So - with the BCH hard fork, didn't that make the bitcoin network less secure (fewer full nodes left)? Did that deficit ever get filled up with newer nodes appearing to fill in the gap? Also, am I understanding correctly that this was a 'contentious' fork (not a planned one)?
user2736158
CC BY-SA 4.0
2018-05-21T21:50:58.330Z
FollowUp on Soft Forks - Are all soft forks backwards compatible? What if one of the rule changes was a block size change? It seems there are cases where soft forks have essentially led to 'orphaned transactions' - transactions that weren't able to be validated because they were sent to nodes following the old rules...
user2736158
CC BY-SA 4.0
2018-05-22T05:30:36.440Z
The BCH fork was both contentious and planned, they are not mutually exclusive. It was planned by some people, and others did not agree with it, therefore it was also contentious. Following the fork, the node count did indeed decrease, however because the majority of users stuck with BTC, the decrease was very small (only a few hundred nodes IIRC) and also had a negligible effect on the network.
Ava Chow
CC BY-SA 4.0
2018-05-22T05:33:42.717Z
All soft forks are backwards compatible. Some consensus rule changes are not backwards compatible and thus cannot be deployed as a soft fork. A transaction that follows the new rules of a soft fork will always be able to be validated by an old node. However the old node will have false positives, i.e. it will determine that a transaction is valid when it is actually invalid under the new rules. An old node cannot have false negatives, i.e. determine a transaction is invalid when it is actually valid. This is because, in general soft forks make things that were valid to be invalid.
Ava Chow
CC BY-SA 4.0
2018-05-26T01:18:44.400Z
@andrew In a hard fork do the forking nodes simply load new binaries and that’s what splits them from the previous chain and enables them to talk to other nodes who forked off also?
Howiecamp
CC BY-SA 4.0
2018-05-26T01:26:11.943Z
@Howiecamp The forking nodes are running a different software which support the fork. They typically do not load new binaries at forking time; rather the binaries that they are running already have support for the fork and wait for some activation condition (e.g. time). Generally, for all forks, to support the new rules, a node must be using different binaries.
Ava Chow
CC BY-SA 4.0
2018-05-21T21:12:36.097Z
2018-05-21T21:12:36.097Z
Ava Chow
<p>A <strong>hardfork</strong> is a rule change that is incompatible with the previous rule set. Thus, any nodes that are not updated to the new rules simply remain on the chain that follows the legacy rule set: unless all miners and nodes update, there will be a non-mending chain split resulting in a new fork coin being created.</p>

<p>A <strong>softfork</strong> is a rule change compatible with the previous rule set, i.e. a tightening of the rules restricting the set of valid blocks to a subset of the previously allowed. As long as the majority of the mining power updates to the new rules, all nodes will converge on the new rules. Miners that have not upgraded to the new rules may occasionally find a new block that is not compatible with the new rules that will be orphaned by the majority mining power.</p>

<p>If both chain-tips use the same rules on crafting transactions, most transactions will be replayable on the other chain. Safe are only transactions that derive from a coinbase output on the corresponding chain-tip or UTXO that have been disintermediated by sending two conflicting transactions on the two chain-tips. An explicit replay protection can be achieved by including a change of the transaction format in the fork-update.</p>

<p>Also see: <a href="https://bitcoin.stackexchange.com/q/30817/5406">What is a soft fork?</a></p>

CC BY-SA 4.0
2018-05-21T22:09:18.553Z
2018-05-21T22:09:18.553Z
Murch
<p>After a hard fork, what happens to the full nodes? Say 11,000 BTC full nodes existed prior to the fork. Do all 11,000 end up supporting both BCH and BTC? Or does BCH start building it's own network of nodes. Not asking about miners, just about full nodes (although, it will help if you can address the mining nodes as well).</p>

<p>Also, in the softfork scenario, I believe the 11,000 nodes are divided - say 7000 support the softfork (e.g. Segwit) and the remaining 4000 do not. In that case, how do transactions remain legit between the supporters and non supporters. </p>

<transactions><bitcoind><blockchain-fork><nodes><soft-fork>
How do the nodes divide after a hard fork? Soft Fork?
user83463
# How do the nodes divide after a hard fork? Soft Fork?

(Asked by: username_0 on 2018-05-21)

After a hard fork, what happens to the full nodes? Say 11,000 BTC full nodes existed prior to the fork. Do all 11,000 end up supporting both BCH and BTC? Or does BCH start building it's own network of nodes. Not asking about miners, just about full nodes (although, it will help if you can address the mining nodes as well).

Also, in the softfork scenario, I believe the 11,000 nodes are divided - say 7000 support the softfork (e.g. Segwit) and the remaining 4000 do not. In that case, how do transactions remain legit between the supporters and non supporters.

**Tags:** transactions, bitcoind, blockchain-fork, nodes, soft-fork


---

## 2 answers

### Answer by username_1 on 2018-05-21. Score: 1

> After a hard fork, what happens to the full nodes? Say 11,000 BTC full nodes existed prior to the fork. Do all 11,000 end up supporting both BCH and BTC? Or does BCH start building it's own network of nodes. Not asking about miners, just about full nodes (although, it will help if you can address the mining nodes as well).

A hard fork means that a new set of consensus rules is being used which splits the blockchain into a blockchain following the old rules and a blockchain following the new rules. There is no "in between" for a node to follow both rules and nodes are not typically equipped to simultaneously support two blockchains.

In the event of a hard fork, the nodes which support the new rules and the hard fork's activation rules will separate from the nodes which do not support the new rules. They become their own network and have their own blockchain. This applies to all full nodes, which miners are a subset of.

So in your example, none of the nodes will support both BCH and BTC unless they were specifically designed to do so. The standard behavior (i.e. nodes using Bitcoin Core for BTC or Bitcoin ABC for BCH) is to only support one chain whose consensus rules are hard coded. Some of those 11,000 nodes will have the BCH rules so they will split from the other nodes which do not have the BCH nodes.

> Also, in the softfork scenario, I believe the 11,000 nodes are divided - say 7000 support the softfork (e.g. Segwit) and the remaining 4000 do not. In that case, how do transactions remain legit between the supporters and non supporters.

A soft fork is backwards compatible with old nodes. It must be designed in a way such that old nodes will not be kicked off of the network after the activation of the soft fork. So for soft forks, the soft fork was designed so that transactions under the new rules are also valid under the old rules. For segwit, this is done by stripping out the segwit specific components which are completely new so that non-segwit nodes are able to parse and validate the transactions.

In a soft fork, there is no chain split and all 11,000 nodes are still using BTC and following the same blockchain.

> **Comments:**
> **username_2**: Thanks. That is super helpful. Followup On Hard Forks - So - with the BCH hard fork, didn't that make the bitcoin network less secure (fewer full nodes left)? Did that deficit ever get filled up with newer nodes appearing to fill in the gap? Also, am I understanding correctly that this was a 'contentious' fork (not a planned one)?  
> **username_2**: FollowUp on Soft Forks - Are all soft forks backwards compatible? What if one of the rule changes was a block size change? It seems there are cases where soft forks have essentially led to 'orphaned transactions' - transactions that weren't able to be validated because they were sent to nodes following the old rules...  
> **username_1**: The BCH fork was both contentious and planned, they are not mutually exclusive. It was planned by some people, and others did not agree with it, therefore it was also contentious. Following the fork, the node count did indeed decrease, however because the majority of users stuck with BTC, the decrease was very small (only a few hundred nodes IIRC) and also had a negligible effect on the network.  
> **username_1**: All soft forks are backwards compatible. Some consensus rule changes are not backwards compatible and thus cannot be deployed as a soft fork. A transaction that follows the new rules of a soft fork will always be able to be validated by an old node. However the old node will have false positives, i.e. it will determine that a transaction is valid when it is actually invalid under the new rules. An old node cannot have false negatives, i.e. determine a transaction is invalid when it is actually valid. This is because, in general soft forks make things that were valid to be invalid.  
> **username_3**: @andrew In a hard fork do the forking nodes simply load new binaries and that’s what splits them from the previous chain and enables them to talk to other nodes who forked off also?  
> **username_1**: @username_3 The forking nodes are running a different software which support the fork. They typically do not load new binaries at forking time; rather the binaries that they are running already have support for the fork and wait for some activation condition (e.g. time). Generally, for all forks, to support the new rules, a node must be using different binaries.  

---

### Answer by username_4 on 2018-05-21. Score: 0

A **hardfork** is a rule change that is incompatible with the previous rule set. Thus, any nodes that are not updated to the new rules simply remain on the chain that follows the legacy rule set: unless all miners and nodes update, there will be a non-mending chain split resulting in a new fork coin being created.

A **softfork** is a rule change compatible with the previous rule set, i.e. a tightening of the rules restricting the set of valid blocks to a subset of the previously allowed. As long as the majority of the mining power updates to the new rules, all nodes will converge on the new rules. Miners that have not upgraded to the new rules may occasionally find a new block that is not compatible with the new rules that will be orphaned by the majority mining power.

If both chain-tips use the same rules on crafting transactions, most transactions will be replayable on the other chain. Safe are only transactions that derive from a coinbase output on the corresponding chain-tip or UTXO that have been disintermediated by sending two conflicting transactions on the two chain-tips. An explicit replay protection can be achieved by including a change of the transaction format in the fork-update.

Also see: [What is a soft fork?](https://bitcoin.stackexchange.com/q/30817/5406)


---

