TL;DR: Where in this code does the SV client figure out that it's not processing an ABC blockchain?

This image 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
  2. Bitcon Cash 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?

2 Answers 2


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 MCCCS mentions, 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.


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.

  • ...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
    Nov 24, 2018 at 17:44
  • 1
    @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
    Nov 24, 2018 at 18:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.