---

SUMMARY

Here's a snapshot of how the top Bitcoin core forks stack up:

Metric	Bitcoin	Litecoin	Bitcoin Cash	Bitcoin SV
Average fee per transaction	$.54	$.0235	$.0034	$.0004
New block creation time	10 minutes	2.5 minutes	10 minutes	10 minutes
Approx. nodes supporting network	9k	1,621	1,429	450
Number of mining pools responsible for over 50% of hashrate	3	​3	1	2
Year established	2009	2011	2017	2018
Supply cap	21m	84m	21m	21m
Circulating Supply	18.10m	63.9m	18.2m	18.2m
Hashing Algorithm	SHA-256	sCrypt	SHA-256	SHA-256

^ As of December 2019.

In analysis of the table above we can see that:

• The block creation process and supply for BitcoinSV are about the same as Bitcoin and Bitcoin Cash. They all use a Proof of Work, SHA-256 hashing algorithm for consensus, and have about the same amount of coins in circulating supply.
• BitcoinSV, in practice, is more centralized than its Bitcoin core counterparts. There are few nodes supporting the network and only a couple mining pools responsible for over 50% of the hash rate in the network. This is detrimental to security because a few large players having majority control of the network leads to easier opportunities for collusion and corruption.  

---

MISSION & NICHE

Per the Bitcoin SV home page:

"It restores the original Bitcoin protocol, will keep it stable, and allow it to massively scale. Bitcoin SV will maintain the vision set out by Satoshi Nakamoto’s white paper in 2008: Bitcoin: A Peer-to-Peer Electronic Cash System. Download the paper... 

Reflecting its mission to fulfil the vision of Bitcoin, the project name represents the “Satoshi Vision” or SV. Created at the request of leading BSV mining enterprise CoinGeek and other miners, Bitcoin SV is intended to provide a clear choice for miners and allow businesses to build applications and websites on it reliably...

Bitcoin, as restored in Bitcoin SV can replace every payment system in the world with a better user experience, a cheaper merchant cost, and a safer level of security...

​Businesses can trust the Bitcoin SV brand to provide the stability and scale they need to commit investment and resources to use the BSV blockchain."

​Insights:

I searched the linked Bitcoin whitepaper for words related to BitcoinSV's differentiation/mission: "scale", "fast", "transactions", "applications" and "websites". There were no results within the Satoshi paper talking about the importance of scaling the system, or building applications on it. 

---

ORIGIN STORY
Disagreements On Consensus Rule Updates, Leading To Forks In The Bitcoin Cash Road

​Bitcoin Cash- the August 2017 hard fork that took the Bitcoin protocol and amended the block size from 1 MB to 32 MB. Pro- When you can fit 32 times more transactions into a block, holding block times constant, you can process 32 times more transactions on the network, making it more competitive with traditional payment networks (like Visa). Con- This eventually leads to a much larger blockchain for users to have to maintain on a given piece of hardware (computer, server, etc.). When the blockchain is smaller, there is incentive for more nodes to run the software and support the network, because it doesn't take up as much space. Here are the details of the two factions that stemmed from Bitcoin Cash:

Bitcoin Cash Faction 1-
​Bitcoin Cash ABC developers, mainly lead by Roger Ver, and Jihan Wu of Bitmain – Developers of the most common Bitcoin Cash node software are referred to as Bitcoin ABC (Adjustable Blocksize Cap) developers. Plans were made by the ABC developers to add new features to the Bitcoin Cash chain, in a non-backwards compatible (hard fork) upgrade. Hard fork upgrade means consensus rules change, so clients (nodes) that don’t upgrade to new rules are unable to follow chain; thus clients that don’t upgrade create a separate fork and are thus running on a different blockchain. The two proposed ABC upgrades were:

• OP_DATASIGVERIFY/OP_CHECKDATASIG- OpCodes (commands) inside the Bitcoin Cash Script language that allows users to validate a signature on a message, in order to verify who the sender is. In Bitcoin, users can check a signature that is signing the transaction with "OP_SIGHASHALL" (checks inputs and outputs involving the generated signature). "OP_DATASIGVERIFY" allows users to sign a separate message as part of a transaction, so they can accept a message that comes from an external source (i.e. oracle that provides signed data about external events). This function is helpful for side chain operations so you can have proof that a message comes from outside the network.
  • OpCodes- Simple functions that operate on data. Low-level, memory efficient, communication with the underlying hardware that's still somewhat legible to human users. There are a lot of OpCodes in the Bitcoin network, each with different functionality. Mainly used as the language that verifies public keys and signatures, to provide secure transactions on the network.   
  • See video below on how electronic signatures work.
• Canonical Transaction Ordering (CTOR) - Changes the way blocks are built and the consensus rules around blocks so that the transactions within a block must be in a specific order. Bitcoin Cash sorts transactions based on alphanumeric ordering of transaction ids, allowing for optimization by ordering outputs then inputs. This ordering allows users to quickly go through all outputs created by transactions in order, then validate all the inputs. This allows for validating in parallel where separate threads validate transactions at the same time. This parallel verification gives opportunity to validate large blocks faster.  For context- in Bitcoin and Bitcoin Cash, transactions are ordered randomly (based on a miner’s preferences) with one main constraint that if two transactions depend on each other (second transaction spends an output created by first transaction) then miners must put them in proper order within the block, so double spends can be detected.

Bitcoin Cash Faction 2-
Bitcoin Satoshi’s Vision, mainly lead by Craig Wright- hard fork of the Bitcoin Cash protocol that occurred in November of 2018. Not all developers agreed on the opcode and CTOR changes, so the Bitcoin Cash SV developers spun off with proposals of:

• 128 MB block increase; from 32 MB in Bitcoin Cash.
• Increase in limit of Bitcoin Script operations within a transaction. More complex scripting operations can allow for contracts, and manipulating numbers in interesting ways. These operations include: OP_MUL; OP_LSHIFT; OP_RSHIFT; OP_INVERT. 

None of the changes proposed by ABC Developers or SV developers were backwards compatible thus they required changes to the consensus rules. When consensus rules change, clients (nodes) that don’t upgrade to new rules are unable to follow the original chain; creating a separate blockchain.

Upgrade disagreements lead to the fork of Bitcoin Cash into “Bitcoin Cash ABC” and “BitcoinSV”. Thus no one continues to mine the original Bitcoin Cash rules.

The disagreements also lead to hashing wars where certain miners were trying to dominate hashing power in the network. During the disagreement, the two factions recruited Bitcoin miners away from the Bitcoin network in order to get more hashing power for their respective sides.

How Digital Signatures Work:

---

How Keys Are Generated:

Simulator: ​https://andersbrownworth.com/blockchain/public-private-keys/keys