<p>It looks like there is no standard on network joins itself together in practice. According to <a href="https://www.investopedia.com/tech/history-bitcoin-hard-forks/" rel="nofollow noreferrer">A History of Bitcoin Hard Forks</a>:</p>
<p>   The fact that no one person or group can determine when and how bitcoin should be upgraded has similarly made the process of updating the system more complex. In the years following the Genesis Block, there have been several hard forks.</p>
<p>Additionally, this is the general rule of hard fork (<a href="https://www.investopedia.com/terms/h/hard-fork.asp" rel="nofollow noreferrer">Hard Fork (Blockchain)</a>):
<a href="https://i.sstatic.net/VQ3GI.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/VQ3GI.png" alt="How Fork Works" /></a></p>

CC BY-SA 4.0
2022-05-10T04:27:44.237Z
2022-05-10T04:27:44.237Z
Cloud Cho
<h2>Ports</h2>
<p>One way that forks can deliberately separate themselves is by using a different TCP port number for network communications.</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Currency</th>
<th>Port</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bitcoin</td>
<td>8333</td>
</tr>
<tr>
<td>Litecoin</td>
<td>9333</td>
</tr>
</tbody>
</table>
</div><h2>Handshake</h2>
<p>When two Bitcoin-like programs communicate with one another, there is an expected initial pattern to the communication, an expected form of data exchanged and some expected data values. We call this a handshake. Programs can use this to identify whether the other program they are communicating with looks sufficiently like themselves (whether their handshake feels right). See <a href="https://en.bitcoin.it/wiki/Protocol_documentation#version" rel="nofollow noreferrer">protocol documentation</a>,  especially version message details and protocol-version number.</p>
<h2>Discovery</h2>
<p>Another route for separation might be differences in <a href="https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery#DNS_Addresses" rel="nofollow noreferrer">the peer-discovery process</a>. It would be natural for dissenting groups creating new forks to replace the seed nodes with ones they run themselves.</p>
<h2>Shunning</h2>
<p>Another mechanism is that BTC nodes reject &quot;bad&quot; data provided by BCH or BSV nodes on port 8333, and vice versa. This is because of consensus rule conflicts. That would eventually cause each set of nodes to blacklist the other. As Pieter Wuille commented: &quot;Relaying an invalid block is a protocol violation (in most cases; there are exceptions), and (in Bitcoin Core) will cause the peer to be considered misbehaving. Misbehaving peers are eventually put on a &quot;discouraged&quot; list, which means their connection slot will be dropped and replaced by another when a non-discouraged IP connects. Bitcoin Core further has a mechanism to temporarily actively seek out extra connections when it appears none of its peers have a recent valid block&quot;.</p>

CC BY-SA 4.0
2022-05-10T11:00:43.517Z
The P2P handshake may also be different (https://en.bitcoin.it/wiki/Protocol_documentation#version). It depends really whether the hard fork was trying to disrupt Bitcoin as much as possible or it was happy to "play nice" and have a different port, P2P handshake etc
Michael Folkson
CC BY-SA 4.0
2022-05-10T12:03:37.433Z
@Michael, Thanks, I'll add that to my answer.
RedGrittyBrick
CC BY-SA 4.0
2022-05-10T12:57:20.990Z
@RedGrittyBrick The shunning is correct. Relaying an invalid block is a protocol violation (in most cases; there are exceptions), and (in Bitcoin Core) will cause the peer to be considered misbehaving. Misbehaving peers are eventually put on a "discouraged" list, which means their connection slot will be dropped and replaced by another when a non-discouraged IP connects. Bitcoin Core further has a mechanism to temporarily actively seek out extra connections when it appears none of its peers have a recent valid block.
Pieter Wuille
CC BY-SA 4.0
2022-05-10T15:17:59.987Z
@Pieter: Thanks, I have added that information to the answer.
RedGrittyBrick
CC BY-SA 4.0
2022-05-11T22:29:59.660Z
Thanks for finding my old question and offering such a well-rounded answer after all these years! Makes sense that any of these mechanisms could keep the forks mostly separate, and especially when working all in combination.
natevw
CC BY-SA 4.0
2022-05-10T09:41:38.103Z
2022-05-10T15:27:09.867Z
2022-05-10T15:27:09.867Z
RedGrittyBrick
<p>I understand that in a hardfork (e.g. the actual Bitcoin vs. Bitcoin Cash/Gold) the blockchains would diverge because the miners and clients have different rules to accept a valid block. It makes sense to me how you could get two or more divergent databases in this way, theoretically.</p>

<p>What's less clear to me is how the actual network joins itself together in practice. Are full nodes on one chain constantly bombarded by the blocks of the other? What keeps a spend [of pre-fork holdings] on one chain from accidentally — or for that matter intentionally! — propagating to the other?</p>

CC BY-SA 4.0
2022-05-25T12:16:08.700Z
Related: https://bitcoin.stackexchange.com/a/111968/5406
Murch
<network><blockchain-fork><consensus><p2p><peer-discovery>
How do hard forks avoid peering with each other?
natevw
# How do hard forks avoid peering with each other?

(Asked by: username_0 on 2017-12-21)

I understand that in a hardfork (e.g. the actual Bitcoin vs. Bitcoin Cash/Gold) the blockchains would diverge because the miners and clients have different rules to accept a valid block. It makes sense to me how you could get two or more divergent databases in this way, theoretically.

What's less clear to me is how the actual network joins itself together in practice. Are full nodes on one chain constantly bombarded by the blocks of the other? What keeps a spend [of pre-fork holdings] on one chain from accidentally — or for that matter intentionally! — propagating to the other?

**Tags:** network, blockchain-fork, consensus, p2p, peer-discovery

> **Comments:**
> **username_1**: Related: https://bitcoin.stackexchange.com/a/111968/5406  

---

## 2 answers

### Answer by username_3 on 2022-05-10. Score: 5 | Accepted answer

## Ports

One way that forks can deliberately separate themselves is by using a different TCP port number for network communications.

| Currency | Port |
| --- | --- |
| Bitcoin | 8333 |
| Litecoin | 9333 |

## Handshake

When two Bitcoin-like programs communicate with one another, there is an expected initial pattern to the communication, an expected form of data exchanged and some expected data values. We call this a handshake. Programs can use this to identify whether the other program they are communicating with looks sufficiently like themselves (whether their handshake feels right). See [protocol documentation](https://en.bitcoin.it/wiki/Protocol_documentation#version), especially version message details and protocol-version number.

## Discovery

Another route for separation might be differences in [the peer-discovery process](https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery#DNS_Addresses). It would be natural for dissenting groups creating new forks to replace the seed nodes with ones they run themselves.

## Shunning

Another mechanism is that BTC nodes reject "bad" data provided by BCH or BSV nodes on port 8333, and vice versa. This is because of consensus rule conflicts. That would eventually cause each set of nodes to blacklist the other. As username_5 commented: "Relaying an invalid block is a protocol violation (in most cases; there are exceptions), and (in Bitcoin Core) will cause the peer to be considered misbehaving. Misbehaving peers are eventually put on a "discouraged" list, which means their connection slot will be dropped and replaced by another when a non-discouraged IP connects. Bitcoin Core further has a mechanism to temporarily actively seek out extra connections when it appears none of its peers have a recent valid block".

> **Comments:**
> **username_4**: The P2P handshake may also be different (https://en.bitcoin.it/wiki/Protocol_documentation#version). It depends really whether the hard fork was trying to disrupt Bitcoin as much as possible or it was happy to "play nice" and have a different port, P2P handshake etc  
> **username_3**: @Michael, Thanks, I'll add that to my answer.  
> **username_5**: @username_3 The shunning is correct. Relaying an invalid block is a protocol violation (in most cases; there are exceptions), and (in Bitcoin Core) will cause the peer to be considered misbehaving. Misbehaving peers are eventually put on a "discouraged" list, which means their connection slot will be dropped and replaced by another when a non-discouraged IP connects. Bitcoin Core further has a mechanism to temporarily actively seek out extra connections when it appears none of its peers have a recent valid block.  
> **username_3**: @Pieter: Thanks, I have added that information to the answer.  
> **username_0**: Thanks for finding my old question and offering such a well-rounded answer after all these years! Makes sense that any of these mechanisms could keep the forks mostly separate, and especially when working all in combination.  

---

### Answer by username_2 on 2022-05-10. Score: 0

It looks like there is no standard on network joins itself together in practice. According to [A History of Bitcoin Hard Forks](https://www.investopedia.com/tech/history-bitcoin-hard-forks/):

   The fact that no one person or group can determine when and how bitcoin should be upgraded has similarly made the process of updating the system more complex. In the years following the Genesis Block, there have been several hard forks.

Additionally, this is the general rule of hard fork ([Hard Fork (Blockchain)](https://www.investopedia.com/terms/h/hard-fork.asp)):
[![How Fork Works](https://i.sstatic.net/VQ3GI.png)](https://i.sstatic.net/VQ3GI.png)


---

