<p>Neither client concretely checks that it's on the wrong chain: BCH and BSV had an unclean split.</p>
<p>Neither changed the network magic, nor did either change their transaction format, so their nodes continued to communicate and transactions remained replayable from one network to the other. As <a href="https://bitcoin.stackexchange.com/a/81330/5406">MCCCS mentions</a>, the two networks started following distinct best chains when each side included transactions that were invalid to the other network. At that point, full nodes were still connected to a mix of nodes of both protocols. They'd get announcements for blocks of either chain. As they download the first block with the new op-codes that were only permitted on one or the other protocol (<code>OP_MUL</code> and <code>OP_DATASIGVERIFY</code>), nodes would try to validate the block, and find the other protocol's block invalid. At that point, they'd ban the node that offered the invalid block and replace the peer with another connection. I think that they'd then at least disconnect or outright ban any new peer that also follows the (from this node's perspective) invalid chain when they get connected. This presumably caused peer churning on both sides until every node eventually made sufficient connections to nodes running the same protocol as themselves.</p>
<p>The screenshot you linked was posted about ten days after the split, so the topology reorganization may have still been on-going at that point (or the screenshot was created a few days before it was (re-)posted).
Especially services monitoring node population could also have been running special crawler-nodes that weren't actually running full node software and thus not announcing blocks, so those would have perhaps lagged behind on noticing the topology split.</p>

CC BY-SA 4.0
2022-04-12T12:27:36.400Z
2022-04-12T12:34:50.777Z
2022-04-12T12:34:50.777Z
Murch
<p>They don't.</p>

<p>They have different, but sometimes common, consensus rules. There are two competing fork blocks with different transaction ordering rules and some transactions with either <code>OP_MUL</code> or <code>OP_DATASIGVERIFY</code>. One of the blocks are valid for that client, followed by many valid blocks. Sometimes, they process transactions of both network, as the replay protection is optional. They simply process if something is valid, or not if it's not.</p>

CC BY-SA 4.0
2018-11-24T17:44:44.240Z
„_...One of the blocks are valid for that client, followed by many valid blocks..._“ — Thanks but that's still unclear to me. Please can you rephrase it to be clearer? Please, bear in mind; I am not an expert like you :) — „_...as the replay protection is optional..._“ — That too. Please paraphrase? Please can you address these original questions also: „_...Is it normal to run a Bitcoin Cash SV client implementation in a Bitcoin Cash ABC network? And vise versa?..._“
algoHolic
CC BY-SA 4.0
2018-11-24T18:00:13.020Z
@algoholic 1) The following blocks are valid to that client, as they use the same consensus rules.2) Transactions made after the fork are valid on both chains by default, unless the different, new added opcodes are used. 3) There's no new network magic. As a result, nodes of different forks can communicate, but not about everything is valid for both. There are different consensus rules which are strictly different. Sorry for the unclear parts, it's definitely my fault.
MCCCS
CC BY-SA 4.0
2018-11-24T17:06:04.427Z
2018-11-24T17:06:04.427Z
MCCCS
<p><strong><em>TL;DR</em></strong>: Where <a href="https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/net_processing.cpp" rel="nofollow noreferrer"><em>in this code</em></a> does the SV client figure out that it's not processing an ABC blockchain?</p>

<hr>

<p><a href="https://i.sstatic.net/JtELh.jpg" rel="nofollow noreferrer"><em>This image</em></a> prompted my question.</p>

<p>There are a couple different mutually incompatible (<em>I am assuming anyway</em>) implementations of the Bitcoin Cash cryptocurrency client software...</p>

<ol>
<li><a href="https://github.com/Bitcoin-ABC/bitcoin-abc/" rel="nofollow noreferrer"><em>Bitcoin Cash ABC</em></a></li>
<li><a href="https://github.com/bitcoin-sv/bitcoin-sv/" rel="nofollow noreferrer"><em>Bitcon Cash SV</em></a></li>
</ol>

<p>My question assumes that each implementation processes their respective transactions using similar but mutually-incompatible blockchain processing rules.</p>

<p>Is it normal to run a Bitcoin Cash SV client implementation in a Bitcoin Cash ABC network? And vise versa? How, then, does one implementation know that the network it is running in, is (<em>in</em>)compatible with its particular processing rules? </p>

<blockchain><client><bitcoin-cash><blockchain-fork>
How do different implementations of the Bitcoin Cash client know which type of coin they're processing?
algoHolic
# How do different implementations of the Bitcoin Cash client know which type of coin they're processing?

(Asked by: username_0 on 2018-11-24)

***TL;DR***: Where [*in this code*](https://github.com/bitcoin-sv/bitcoin-sv/blob/master/src/net_processing.cpp) does the SV client figure out that it's not processing an ABC blockchain?

---

[*This image*](https://i.sstatic.net/JtELh.jpg) prompted my question.

There are a couple different mutually incompatible (*I am assuming anyway*) implementations of the Bitcoin Cash cryptocurrency client software...

1. [*Bitcoin Cash ABC*](https://github.com/Bitcoin-ABC/bitcoin-abc/)
2. [*Bitcon Cash SV*](https://github.com/bitcoin-sv/bitcoin-sv/)

My question assumes that each implementation processes their respective transactions using similar but mutually-incompatible blockchain processing rules.

Is it normal to run a Bitcoin Cash SV client implementation in a Bitcoin Cash ABC network? And vise versa? How, then, does one implementation know that the network it is running in, is (*in*)compatible with its particular processing rules?

**Tags:** blockchain, client, bitcoin-cash, blockchain-fork


---

## 2 answers

### Answer by username_1 on 2022-04-12. Score: 1

Neither client concretely checks that it's on the wrong chain: BCH and BSV had an unclean split.

Neither changed the network magic, nor did either change their transaction format, so their nodes continued to communicate and transactions remained replayable from one network to the other. As [username_2 mentions](https://bitcoin.stackexchange.com/a/81330/5406), the two networks started following distinct best chains when each side included transactions that were invalid to the other network. At that point, full nodes were still connected to a mix of nodes of both protocols. They'd get announcements for blocks of either chain. As they download the first block with the new op-codes that were only permitted on one or the other protocol (`OP_MUL` and `OP_DATASIGVERIFY`), nodes would try to validate the block, and find the other protocol's block invalid. At that point, they'd ban the node that offered the invalid block and replace the peer with another connection. I think that they'd then at least disconnect or outright ban any new peer that also follows the (from this node's perspective) invalid chain when they get connected. This presumably caused peer churning on both sides until every node eventually made sufficient connections to nodes running the same protocol as themselves.

The screenshot you linked was posted about ten days after the split, so the topology reorganization may have still been on-going at that point (or the screenshot was created a few days before it was (re-)posted).
Especially services monitoring node population could also have been running special crawler-nodes that weren't actually running full node software and thus not announcing blocks, so those would have perhaps lagged behind on noticing the topology split.


---

### Answer by username_2 on 2018-11-24. Score: 0

They don't.

They have different, but sometimes common, consensus rules. There are two competing fork blocks with different transaction ordering rules and some transactions with either `OP_MUL` or `OP_DATASIGVERIFY`. One of the blocks are valid for that client, followed by many valid blocks. Sometimes, they process transactions of both network, as the replay protection is optional. They simply process if something is valid, or not if it's not.

> **Comments:**
> **username_0**: „_...One of the blocks are valid for that client, followed by many valid blocks..._“ — Thanks but that's still unclear to me. Please can you rephrase it to be clearer? Please, bear in mind; I am not an expert like you :) — „_...as the replay protection is optional..._“ — That too. Please paraphrase? Please can you address these original questions also: „_...Is it normal to run a Bitcoin Cash SV client implementation in a Bitcoin Cash ABC network? And vise versa?..._“  
> **username_2**: @username_0 1) The following blocks are valid to that client, as they use the same consensus rules.2) Transactions made after the fork are valid on both chains by default, unless the different, new added opcodes are used. 3) There's no new network magic. As a result, nodes of different forks can communicate, but not about everything is valid for both. There are different consensus rules which are strictly different. Sorry for the unclear parts, it's definitely my fault.  

---

