user26673: 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?

user13866: 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,  especially version message details and protocol-version number.
Discovery
Another route for separation might be differences in the peer-discovery process. 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 Pieter Wuille 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".

26673: <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>
 13866: <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>
