The Original Bitcoin Protocol:

What is it and why does it matter?

Prepared by MNP

August 25th, 2021

About MNP
MNP is a leading national accounting, tax, and business consulting firm in Canada. We proudly
serve and respond to the needs of our clients in the public, private and not-for-profit sectors.
Through partner-led engagements, we provide a collaborative, cost-effective approach to doing
business and personalized strategies to help organizations succeed across the country and around
the world.

Disclaimer
The opinions and conclusions identified in this independent review of the original Bitcoin protocol
do not constitute a legal opinion, nor do they constitute a third-party attestation or statement of
audit opinion as defined by the American Institute of Certified Public Accountants / Chartered
Professional Accountants (AICPA/CPA Canada) rules and definitions. This assessment makes no
warranty regarding the claims made about the current or future state of the Bitcoin ecosystem and
its various implementations. This assessment was performed at a point in time based on resources
available. Someone else with different access and different resources may have different results. If a
third-party is to rely on this report, it is important to understand context, limitations of our analysis
and our research approach, and therefore written consent from MNP must be arranged.

ii
Purpose of this document
The purpose of this report is to determine by comparison which current Bitcoin implementation is
the most accurate representation of the vision proposed by Satoshi Nakamoto (“Satoshi”), the
pseudonymous creator of the original Bitcoin protocol.

Satoshi’s original intention and vision for Bitcoin were established by examining source material
related to the development of the original Bitcoin protocol and the Bitcoin network, either authored
by or directly involving Satoshi himself. The original source material includes publicly available
content such as online forum posts, emails, original source code for the first version of the Bitcoin
software, and the Bitcoin whitepaper.

This report summarizes the context, methodologies used, and conclusions in the following sequence:

1. Setting the stage

2. Establishing Satoshi’s original vision
3. Defining Satoshi’s Bitcoin
4. Aligning current implementations to Satoshi’s vision
5. Impact of Satoshi’s vision once fully realized

Scope and approach

To perform the independent review of the Bitcoin ecosystem, the following areas were assessed for
the Bitcoin Core (“BTC”) and Bitcoin Satoshi Vision (“BSV”) implementations in comparison to the
original Bitcoin protocol:

• Capabilities
• Functional requirements
• Non-functional requirements
• Implementation attributes

The review was performed between February 8 and June 4, 2021. Accordingly, our results are based
upon information available to us during that timeframe. All conclusions and key findings were
based on the following assessment procedures:

• Defining key criteria of the “original Bitcoin protocol” (ruleset for the Bitcoin network)
released by Satoshi.
• Reviewing publicly available content and documentation to assess each protocol
implementation against assessment criteria.
• Comparing source code of Satoshi’s original Bitcoin software version 0.1.0 to BTC version
0.21.0 and BSV version 1.0.7
• Conducting interviews with key stakeholders and subject matter experts on the current
state of examined Bitcoin implementations

iii
Limitations, boundaries, and exclusions
Source code for the Bitcoin software is limited to all versions from 0.1.0 until release of version 0.1.5,
as there is evidence of larger community involvement in the development of the software thereafter.
The software versions 0.1.0 through 0.1.5 are recognized as versions released by Satoshi.

For the purposes of this report, the scope was limited to examining the original Bitcoin protocol
(circa 2009-2011) and contrasting it with BTC and BSV implementations as of March 31, 2021.

Due to time and material constraints, other forks of the original Bitcoin protocol were excluded.

The following review areas were not addressed as part of the independent review:

• Valuation - There is no intent to address the mechanisms that inform the market pricing of
any digital cash mentioned in this paper. If mentioned, any forward-looking valuations are
purely hypothetical and do not constitute investment advice.
• Reputation - There is no intent to address the public perceptions of any digital cash and/or
the operators of the digital cash networks mentioned in this report.
• Previous forks - The analysis of previous forks such as Bitcoin Cash, BitcoinABC, and BitcoinXT
are not included in this report.

For more information on cryptocurrency or for any questions regarding the information found in
this report, please contact Hash Qureshi, Partner, Enterprise Risk Services at Hash.Qureshi@mnp.ca

iv
Summary of findings
This report reviewed Satoshi’s writings for the implementations of the Bitcoin network, the associated
software and code, and the Bitcoin protocol. Source material for our review included Satoshi’s
whitepaper, emails, forum posts, and original code, which are all publicly available. These source
materials were used to determine Satoshi’s original purpose for Bitcoin.

Based on our review, Bitcoin was intended to be a transaction network for digital cash to compete
as a global payment system. Current implementations (BSV and BTC) were compared against that
original vision. Our findings indicate BSV is most representative of Satoshi’s original intention for
Bitcoin. We used an assessment framework and resulting criteria — including OpCodes, Bitcoin
scripting, and protocol elements — to assess the protocols described in this paper.

iv
Contents
About MNP ............................................................................................................................................................. ii
Disclaimer ................................................................................................................................................................ ii
Purpose of this document ................................................................................................................................ iii
Scope and approach ........................................................................................................................................... iii
Limitations, boundaries, and exclusions ...................................................................................................... iv
Summary of findings .......................................................................................................................................... iv

1. Setting the stage ....................................................................................................................... 7

2. Establishing Satoshi’s original vision................................................................................... 8
2.1 Sources of information................................................................................................................................. 8
2.1.1 The Bitcoin whitepaper ............................................................................................................................. 8
2.1.2 Other sources ............................................................................................................................................... 9
2.1.3 Bitcoin v0.1.0 ALPHA ............................................................................................................................... 10
3. Defining Satoshi’s Bitcoin ...................................................................................................... 11
3.1 The Bitcoin protocol ..................................................................................................................................... 11
3.2 Capabilities ..................................................................................................................................................... 12
3.2.1 Transaction validation ............................................................................................................................ 12
3.2.2 Identity security ........................................................................................................................................ 13
3.2.3 Network access ......................................................................................................................................... 13
3.3 Critical components .................................................................................................................................... 14
3.3.1 Timestamp server ..................................................................................................................................... 14
3.3.2 Proof of work............................................................................................................................................. 14
3.3.3 Incentives .................................................................................................................................................... 15
3.3.4 Policies.......................................................................................................................................................... 15
3.3.5 Independence from trusted third parties ...................................................................................... 16
3.3.6 Stakeholders .............................................................................................................................................. 16
3.3.7 Network and blocks ................................................................................................................................ 16
3.3.8 Security......................................................................................................................................................... 17
3.4 Non-functional requirements ................................................................................................................. 18
3.4.1 Integrity, transparency, and auditability ........................................................................................ 18

5
 3.4.2 Availability .................................................................................................................................................. 19
3.4.3 Scalability .................................................................................................................................................... 19
3.5 Implementation Attributes....................................................................................................................... 19
3.5.1 Block size ...................................................................................................................................................... 19
3.5.2 Economic incentives .............................................................................................................................. 20
3.5.3 Consensus mechanisms ........................................................................................................................ 21
3.5.4 OpCodes and scripting .......................................................................................................................... 21
3.6 Analysis of Bitcoin software v0.1.0 ALPHA .........................................................................................22
3.7 Satoshi’s original vision .............................................................................................................................23

4. Comparing current implementations to Satoshi’s vision .......................................... 24

4.1 Description of assessment framework .................................................................................................25
4.2 Comparison of implementations ...........................................................................................................25

5. Impact of Satoshi’s visions once fully realized...............................................................37

5.1 Electronic cash / payment system vision .............................................................................................37
5.2 Other use case elements in the vision..................................................................................................38

6. Summary and conclusion .................................................................................................... 40

Bibliography ..................................................................................................................................... 42
Annex ................................................................................................................................................. 43
Annex 1: Energy calculations.......................................................................................................................... 43
Annex 2: OpCodes ............................................................................................................................................. 45
Annex 3: Source code timeline ......................................................................................................................56
Annex 4: Risk and control framework based on the whitepaper ......................................................63
Annex 5: Highlights of major Bitcoin and BSV protocol changes.................................................... 64

6
1. Setting the stage
More than a decade has passed since the original Bitcoin whitepaper Bitcoin: A Peer-to-Peer [P2P]
Electronic Cash System1 was posted in October 2008 and the Bitcoin blockchain was launched in
January 2009. Since then, the concepts of distributed ledger technology and blockchain have
become a regular feature in global media and public discourse. Once a fringe idea, blockchain-based
digital cash is now an accepted and well-recognized method for handling transactions and has spun
out a new industry with many competing blockchains and distributed ledger technologies.

Given the rise in popularity of this new technology, it is important to reinforce the correct
understanding of the blockchain movement by returning to its roots and examining the original
vision of Satoshi Nakamoto, the pseudonymous creator of Bitcoin. With Satoshi’s vision for Bitcoin
in mind, the objective of this report is to examine the differences between two current competing
blockchains that stem from the original Bitcoin blockchain, determine which blockchain best aligns
to Satoshi’s original vision, and more importantly, assess why that is important.

The original Bitcoin protocol2 was proposed and — initially — solely developed by Satoshi. In the
years prior to 2008 and 2009, Satoshi quietly developed the original code base of the Bitcoin software
as proof of concept. After the protocol was revealed on the Metzdowd cryptography email list, the
Bitcoin vision was supported by some early adopters. For a small period after the release of the
software, Satoshi continued to play a key role in the development and maintenance of the Bitcoin
project.

By 2010, a larger development community started forming around Bitcoin. The project would see
many contributors to the Bitcoin software. Consensus is Satoshi last posted on the Bitcoin Forum3 in
December 2010.

For several years after Satoshi’s departure from Bitcoin, the project evolved in response to what these
early developers felt Satoshi wanted; they made decisions they felt would grow and promote a
successful implementation of Bitcoin. The original Bitcoin protocol was modified and continued to
evolve without Satoshi’s involvement. Development was instead directed by developers who were
not involved in Bitcoin’s creation but who had their own views, intentions, and visions.

It was not long before early supporters of Bitcoin started to have a larger community supporting and
transacting in the new digital cash. Like all communities, there were numerous opinions as to how
the protocol should be developed and scaled (or not). With growing popularity and varied ideas on
how the protocol should be developed, Bitcoin went through a series of forks4.

1
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
2
In computer science, a protocol is a set of rules or procedures for transmitting data between devices, such as a computer. For Bitcoin,
these are the rules in which transaction data is transmitted across the Bitcoin network.
3
Nakamoto, S. (2010). Bitcoin Forum. https://Bitcointalk.org/index.php?action=profile;u=3;sa=showPosts
4
In software engineering, a fork occurs when developers take the source code for an existing project and use it to create new software.

7
With a bit of history out of the way, and with the rise of alt-chains5 deriving from the Bitcoin protocol,
there are some important questions:

• What was Satoshi’s original vision for Bitcoin?

• What attributes of the original Bitcoin protocol are key to realizing the full benefits of this
vision?
• Which current implementation of Bitcoin protocol conforms most completely to these
attributes and therefore is most likely to realize Satoshi’s original vision?

The remainder of this report will focus on answering the questions above. Section 2 aims to
establish the validity of the source material and summarize findings regarding Satoshi’s original
vision. Section 3 examines the original Bitcoin protocol and the key attributes for realizing the
benefits of this vision. Section 4 compares the BTC implementation and the BSV implementation to
the vision as establish in sections 2 and 3. Section 5 examines the potential future state if Satoshi’s
original intentions were met. Finally, Section 6 provides concluding remarks. Additional detail is
supported through Annexes.

2. Establishing Satoshi’s original vision

2.1 Sources of information

To understand Satoshi’s intentions regarding the Bitcoin project, it is important to establish a set of
base truths. Several primary source documents can be reasonably relied upon to define exactly what
Satoshi’s vision for Bitcoin was. These include:

- The original Bitcoin whitepaper posted in 2008.

- Early versions of the codebase including known Satoshi's versions of the Bitcoin software.
- Known emails from Satoshi, as summarized on the Metzdowd Forum.
- Posts by Satoshi, as summarized on Bitcoin Forum and P2PFoundation.

2.1.1 The Bitcoin whitepaper

The Bitcoin whitepaper was the first published work associated within the Bitcoin project (distributed
through the Metzdowd cryptography email list) and is a primary source that Satoshi had complete
control over. It is possible to download the original version of the whitepaper from the Bitcoin
blockchain itself.

In the whitepaper, Satoshi underlines his proposal that “[a] purely peer-to-peer6 version of electronic
cash would allow online payments to be sent directly from one party to another without going

5
An alt-chain is the result of a new chain being created from a fork of the original chain.
6
In computer networking, Peer-to-Peer (P2P) refers to a network in which each computer can act as a server for the others, allowing
shared access to files and peripherals without the need for a central server.

8
through a financial institution… [with] a solution to the double-spending7 problem using a peer-to-
peer network.8'' Satoshi details nine key areas of his proposed solution in the publication including:

• How transactions work

• The operations of the timestamp server9
• The implementation of a proof of work (“PoW”)
• How the network communicates
• The network participation incentives
• The methods to reclaim disk space
• The future state operations
• How transactions are sent through the network
• Privacy considerations

The whitepaper provides an entry point into the functional and operational requirements that make
the original Bitcoin protocol work. In addition, Satoshi provides evidence supporting the validity of
the solution to the double-spending problem that perplexed previous attempts at creating an
electronic cash system. The whitepaper begins to outline what this technology could start to support
and how different types of users would use the system . It also establishes a set of ground rules to
enable development of the technology.

2.1.2 Other sources

Other important primary sources come from known online forum postings, writings, and emails that
were exchanged between Satoshi and early Bitcoin enthusiasts. These digital communications offer
a window into Satoshi’s mind and paint a picture of how input from the digital cash and related
communities was handled. There were mainly three topics of discussion that Satoshi was involved in
with early Bitcoin adopters.

First, there were discussions about the validity of the proposed P2P electronic cash transaction
system. These types of questions and responses provide a deep insight into how the original
proposition was intended to function. These early conversations are mainly from the Metzdowd email
list which consisted of the earliest members of Bitcoin’s online community.

Second, there were questions around the different use cases of the proposed Bitcoin electronic cash
system. There were community discussions about using Bitcoin for paid email services and vending
machines. Satoshi often validated how Bitcoin could be used to handle these types of business
transactions.

Finally, there were general tech support and administerial questions. These stemmed from users
reporting bugs, having problems setting up the software, providing community members access to
code so they could help translate the application into different languages, and users providing status

7
In digital cash there is a unique problem wherein the currency could be spent more than once by an individual who understands how a
particular system works at a programming level.
8
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
9
A timestamp server cryptographically validates a digital signature took place at a specific point in time.

9
updates on new builds. These threads reveal how hands on Satoshi was in the earliest years of the
original Bitcoin protocol.

2.1.3 Bitcoin v0.1.0 ALPHA

“I'm better with code than with words, though.” – Satoshi Nakamoto, 200810

While this report relies on publications and written communications as primary source documents,
it is just as important to examine the original source code of the Bitcoin software released by Satoshi,
which represented his implementation of the original Bitcoin protocol. The earliest versions of the
codebase for the Bitcoin software can still be accessed. This provides insight into the software, its
potential functionality, and what the Bitcoin project was intended to become.

Several versions of the original Bitcoin software were released while Satoshi was recognized to be
involved with the project. Satoshi first shared the pre-release version with a few select users of the
Metzdowd group who contacted him personally. Like the whitepaper, this source code is likely11 the
original version created by Satoshi.

As the project took shape and gained acceptance, Satoshi started to add developers from the online
community. Notably, Hal Finney12 was among the first people to start contributing to the project. As
the project evolved, the code was increasingly derived from community input rather than from
Satoshi.

With that in mind, it can be concluded that the pre-release and version 0.1.0 of the Bitcoin software
are the versions where Satoshi had the most influence. A later version could have been included,
however, after version 0.1.5, most of the core components had been set. For the purposes of
establishing how Satoshi intended the Bitcoin software to work, this report relies on code up to
version 0.1.0, as most updates following the version 0.1.0 release are security-related or bug fixes.

Summary of material

The whitepaper, forum posts, emails, source code, and other writings provide the necessary
elements to establish a set of criteria for examining the differences between current Bitcoin
implementations. There is indication of the proposed system’s capabilities, functional requirements,
non-functional requirements, and implementation attributes throughout the writings.

The following section will define, as from the source material, what the Bitcoin protocol is and how
Bitcoin operates — and finally, summarize what Satoshi’s original intentions were for the Bitcoin
protocol itself.

10
Nakamoto, S. (2008). Metzdowd emailing list. https://www.metzdowd.com/pipermail/cryptography/2008-November/014853.html
11
While there is no way to verify that the code is truly authentic, this is generally accepted to be the case.
12
Hal Finney was the first person to receive a Bitcoin transaction. He was also the first person to be added to the developers list on
Sourceforge to write code other than Satoshi.

10
3. Defining Satoshi’s Bitcoin

Relying on the gathered primary source material, Satoshi’s original vision for Bitcoin can be
established and defined. The following will outline and summarize the findings from the
whitepaper, forum posts, emails, original source code, and other writings.

3.1 The Bitcoin protocol

A protocol is “a set of rules governing the exchange or transmission of data between devices.”13 In
the case of cryptocurrencies, a protocol is a set of rules that enables communication between
systems and informs the structure of a blockchain.14 For Bitcoin, Satoshi’s original protocol defines
the rules which the nodes of the transaction network will follow.

The table on the following page represents the phases of communication through the network and
what nodes do during those steps:

Table 1 – Bitcoin protocol phases

Step 1: Step 2: Step 3: Step 4: Step 5: Step 6:

Broadcast Block of Proof Broadcast Accept New New Block
Transactions of Work PoW Block in Chain
(“PoW”)
Phase New Each node Each When a Nodes accept Nodes
Transactions collects new node node finds its the block only Express their
Description
are broadcast transactions works on PoW, it if all accpetance
to all nodes. into a block finding a broadcasts transactions in of the block
difficult the block to it are valid and by working
PoW for all nodes not already on creating
its block spent the next
block in the
chain using
previous
hash.
Electricity Low High High Low Low Low
Consumption
Nodes – CPU      
Network      
Communication
Disk and      
Memory

13
Definition of “protocol” from https://www.lexico.com/definition/protocol
14
Each block, and the contents of a block, are written and communicated in an exact manner.

11
There are several immutable rules common among all Bitcoin implementations:15,16

• The sum of the value of the inputs of a transaction must be greater than or equal to the sum of
the values of the outputs.
• The block reward subsidy will drop by half at a scheduled rate of every 210,000 blocks, starting
with a subsidy of 5 billion satoshis17 per block from the Genesis block18.
• The network will adjust the target for the difficulty of the PoW needed for a valid block to
maintain an approximate 10-minute block discovery rate.
• Only blocks that add to the blockchain formed by building upon the Genesis block are valid.
• The structure of the Bitcoin database as a distributed timestamp server validating chains of
transaction outputs.
• Transaction data formatting, including sizes of certain fields and their encoding schema.
• Block structure and header information including sizes of certain fields and their encoding
schema.
• The Bitcoin scripting language and its specification including lists of opcodes that are usable in
script and the exact outcome of their execution.
• Bitcoin source code should always be open for anyone to read, modify, copy, and/or share.
• All coins are equal and should be equally spendable.
• Confirmed blocks should be set in stone. Blockchain history should be immutable.

3.2 Capabilities
What does Bitcoin even do? Is it cash? Is it digital gold? To discuss the capabilities of Bitcoin, it is
important to first understand the difference between a bitcoin and the Bitcoin network. A bitcoin is
a unit of account that allows an individual to transact on the Bitcoin network. It is the capabilities of
this network — the rails of a payment system — that make Bitcoin what it is: a network that processes
and validates digital transactions.

The capabilities of Bitcoin can be broken down into three areas: transaction validation, identity
security, and network access.

3.2.1 Transaction validation

A critical aspect of any merchant’s digital payment system is a means to validate that-no amount is
double spent. This double-spending problem is particularly important for payment networks that
rely on digital transactions. Double spending could potentially cause a conflict whereby it is not
known who owns an amount of digital cash. With Bitcoin, this is resolved by a rather elegant solution
to the Byzantine General’s Problem.19

15
Bitcoinsv Wiki. (n.d.). Bitcoinsv. Retrieved May 21, 2021, from https://wiki.Bitcoinsv.io/index.php/Protocol
16
Bitcoin Wiki. (n.d.). Bitcoin Community. Retrieved May 21, 2021, from https://en.Bitcoin.it/wiki/Principles_of_Bitcoin
17
A satoshii is the smallest unit of the Bitcoin token. It is equivalent to 1/100 millionth of a Bitcoin.
18
The Genesis Block is the first block in the chain of blocks that makes up the blockchain
19
The Byzantine General’s problem is a situation where involved parties must agree on a single strategy in order to avoid failure, but
where some of the involved parties are corrupt and are giving false information.
12
Prior to Satoshi’s proposal, there was no appropriate solution to the double-spending problem
amongst other proposed digital transaction systems. Anyone who sufficiently understood a digital
cash system could theoretically duplicate transactions and potentially defraud merchants or
individuals receiving a payment. To avoid this, Satoshi proposed a system that used “a peer-to-
peer distributed timestamp server” to generate computational proof of the chronological order of
transactions. The system is secure as long as honest nodes collectively control more CPU power
than any cooperating group of attacker nodes.”20

3.2.2 Identity security

The whitepaper describes a unique system which gives users an important option for identity
security. The system is a distributed network that was specifically designed so the security and
integrity of the solution do not rely on a third-party (requiring trust outside of the distributed
network). This trust also often led to requiring the exchange of personal information. By 2009 data
breaches were becoming extremely common, substantially increasing the threat of identity fraud.
Satoshi deemed a payment system that can provide users an added level of security to prevent
identity theft to be essential.21

In order to have a system without a trusted third-party, Satoshi’s proposal relied on a network of
nodes to write new blocks to the chain.22 For node operators to participate in the transaction network,
there must be some sort of economic incentive. With Bitcoin, node operators would have two such
mechanisms: First, a number of “fresh” coins are distributed through a gradually decreasing subsidy
from the fixed 21 million bitcoin supply for winning the right to create a new block of transactions.
Second, transaction fees are paid by senders of coins for all transactions collected into a block, which
should continue to increase over time until all 21 million Bitcoin tokens have been distributed into
circulation through the block generation process.23

3.2.3 Network access

There are early online forum discussions regarding what a Bitcoin token is. Satoshi references the
Bitcoin token as something like a store of value (gold) or collectable.24 However, it is clear through
analysis of the source code that a bitcoin is a necessary element of the system for users to access
and use the distributed transaction network. It must have some value attached to it which gives node
operators an economic incentive to provide computing power to run the network. The long-term
value of a bitcoin was left for the markets to decide. However, there needs to be digital cash to run
a distributed timestamp server and distributed digital transaction system.

Apart from potential value, issues of scalability were some of the first questions brought up by
forum users. In the forums, whitepaper, and emails, Satoshi regularly discussed scalability of the
Bitcoin network and provided no reason to believe there should be limits to its potential scalability

20
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
21
Ibid
22
A node is a connection point within a network that can send, receive, create, or store data. This could be a single CPU.
23
A Bitcoin is minted / created when a new block is successfully added to the ledger. Further discussion of this process is in section is
below.
24
Nakamoto, S. (2010). Bitcoin Forum. https://Bitcointalk.org/index.php?topic=845.msg11403 - msg11403
13
and growth. In his response to the questions about scalability dating to 200925, it is apparent he
believed the protocol and network should be able to handle transactions loads comparable to
Visa’s credit card processing network.

3.3 Critical components

Through the analysis of Satoshi’s writings, several critical components arise which are key to the
operations of the Bitcoin network. These include a timestamp server, PoW mechanisms, incentives,
policies, independence from third parties, stakeholders, network and blocks, and security.

3.3.1 Timestamp server

The timestamp server is the first step in the process of creating the digital ledger. It provides
cryptographic evidence the data existed at a given time. In the case of Bitcoin, this includes any
transactions that happened between addresses26 in a given timeframe.27 Each timestamp block also
contains the hash28 of the previous timestamp and is chained together.29 This server takes the hash
of a block of items and publishes it for all to see. The process of hashing the previous block and
appending it to the new block creates a large chain, which is the basis of Bitcoin. The timestamp
server is the cornerstone that builds the Bitcoin transaction ledger.

3.3.2 Proof of work

To have a distributed timestamp server, Satoshi proposed implementing a Hashcash30 style
PoW31,32 in combination with the timestamp server. CPU effort is used to satisfy the PoW. As new
blocks get added, this method makes it increasingly difficult to change previous blocks because
work would need to be completed again.

PoW is the system used by Bitcoin to validate all transactions and blocks. The concept begins by
scanning for a value that, when hashed with SHA-256, has a beginning with a certain number of
zero bits.33 This process can be made more difficult by increasing the required number of zeros or
made less difficult by reducing the number of zeros. This is the basis of work. Using the hash of
multiple values and an increasing nonce, a CPU can find a solution with the required amount of
beginning zeros after a certain period of effort. Once the required work has been completed, the
block is chained to the previous one and this process continues.

For someone to make a change to this block, they would need to redo all the work of the blocks
chained after it. Miners attempting this type of attack cannot be anonymous — they would be a

25
Nakamoto, S. (2008). Metzdowd emailing list. https://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html
26
In Bitcoin, an address is the only information passed to the network. Addresses can send and receive transactions.
27
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
28
A hash function is any function that can be used to map data of arbitrary size to fixed-size values.
29
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
30
Hashcash is a proof-of-work algorithm and was invented by Adam Back in 1997
31
Proof-of-Work is a form of cryptographic zero-knowledge proof in which one party (the prover) proves to others (the verifiers) that a
certain amount of effort has been expended. Verifiers can subsequently confirm this expenditure with minimal effort on their part.
32
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
33
Ibid
14
known entity to the network. This confirms the solution to the Byzantine General’s Problem, as
majority decision-making is not necessary.

PoW is equivalent to one-CPU, one vote. The longest chain has the greatest amount of work
invested. In order to rewrite the chain, an entity would need more than 51 percent of the available
CPU power to create and maintain a longer chain. Provided majority CPU power is controlled by
honest nodes, the chain will grow faster than any other.

3.3.3 Incentives
To incentivize node operators to provide their CPU power to the network, they are rewarded every
time they win the right to create a new block and add it to the chain. Specifically, the winning node
operator is rewarded with amounts of bitcoin. The total supply of bitcoin is limited to 21 million
coins, with “fresh” coins circulated to the winning node operator for every successful block (in the
number of the fixed “subsidy” portion of the block reward).

The subsidy portion of the block reward is halved every 210,000 blocks. The original subsidiary
amount of the block reward was 50 bitcoin. Approximately every four years, it halves — first to 25,
then 12.5, 6.25 (currently), 3.125, and so forth until the full 21 million supply of “fresh” coins is
distributed into circulation. As the number of fresh coins from the 21 million supply goes into the
network circulation, Satoshi indicated transaction fees (also earned by winning node operators for
each block) needed to grow as replacement for the diminishing block rewards, especially once the
21 million supply limits of fresh coins are reached.34

3.3.4 Policies
There are policies which differ for each Bitcoin implementation. Most of these changes have to do
with block sizes. The original block size was set to 32 megabytes (MB) by Satoshi35 and later set to 1
MB with intentions to increase it in the future.36 The major forks of the Bitcoin network represent
differences in approach as to whether there should be a developer-controlled default maximum on
the block size. A larger block size allows more individual transactions and more overall data to be
processed per block.

One of the most debated mutable components of all versions of Bitcoin is the block size.
Differences in philosophy about the maximum default block size is a key trigger for hard forks in
the history of Bitcoin — although other software differences such as the controversy over BTC’s
addition of the Segregated Witness37 function in 2017 have also triggered hard forks — including a
division of the Bitcoin network between BTC and Bitcoin Cash (“BCH”).

Once an incompatible block (with higher block size or other incompatible rule elements) is mined
on a network that has changed its rules, the newer software essentially creates a new branch on

34
Nakamoto, S. (2010). Bitcoin Forum. https://Bitcointalk.org/index.php?topic=994.msg12168 - msg12168
35
MAX_SIZE is a constant variable defined in “main.h” of BTC v0.1.0 ALPHA. This variable is used to ensure that the vector of transactions
is smaller than 32mb. Since all other elements of block header are of negligible size, the overall block size was approximately 32mb.
36
Nakamoto, S. (2010). Bitcoin Forum https://bitcointalk.org/index.php?topic=1347
37
Segregated Witness was a soft fork under BIP141 that removed signature data from the BTC blockchain to mitigate a blockchain size
limitation problem
15
the longest chain, then rejects transactions from the older software. The older software can
continue by adding blocks compatible with its rule set on the older branch. This creates two
different branches of the original chain if a software update is not fully accepted by all users.

3.3.5 Independence from trusted third parties

Bitcoin is meant to be a P2P electronic payment system as described by Satoshi in his original post
with the whitepaper.38 This electronic payment system is built on PoW, rather than trust in a third-
party, to validate a transaction has occurred.39 The Bitcoin blockchain can be compared to a digital
ledger. There is a lump sum of Bitcoin, and fresh coins from that supply are distributed based on
transactions to different participating parties.

Our stance regarding trusted third parties has been derived from the whitepaper:

"A purely peer-to-peer version of electronic cash would allow online

payments to be sent directly from one party to another without going
through a financial institution."40

In our analysis, we are including cryptocurrency exchanges as trusted third-party institutions. It's
not about avoiding third parties but aligning with the new privacy model proposed in the
whitepaper. Using an exchange is a point where private information would need to be disclosed,
which does not conform to the privacy model set forth in the whitepaper. An individual would still
need to know the third-party whom they are sending / receiving payments.

3.3.6 Stakeholders
The primary stakeholders of Bitcoin are the entities directly related to the P2P electronic cash
system. This includes holders / users of Bitcoin, node operators, and developers. Node operators
ensure transactions are validated and processed, blocks are broadcast to other nodes, and blocks
with valid transactions are accepted and added to the blockchain.

There are secondary stakeholders for the Bitcoin network which are necessary for the system to
function. These include electricity providers, hardware providers, and internet service providers.
With a shortage of any, the system integrity is potentially at risk.

3.3.7 Network and blocks

Communication within the Bitcoin network is handled by nodes. These nodes are connected to
several peers which eventually create a massive network as more nodes join the network. Nodes
can freely enter and exit the network. These nodes allow a block’s transactions to be broadcast and

38
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
39
Ibid
40
Ibid
16
stored (if the new block is accepted) at the leaves of Merkle trees41 of other nodes.42 They are then
hashed upwards together, branch by branch, until the root is reached. With the hashed root and
the block header of the previous block, a node can begin trying to compete for the next block.
Once found, the header of the block is created, and the node broadcasts the solution to other
nodes for verification — increasing the length of the chain.

To elaborate, the block header is an 80-byte-long string containing the Bitcoin version number, the
previous block hash of the Merkle root, a timestamp of the block, a difficulty target for the block,
and a nonce. This structure applies to all blocks except the first in the blockchain (also known as
the Genesis Block).43

For a node to join the network, it must download the Bitcoin software and run it. The node will first
download and validate the entire chain. Once that is done, the node will then be able to
communicate with its peers using the Transmission Control Protocol (“TCP”). All communications
for Bitcoin are done over TCP.

Satoshi‘s whitepaper outlines the following base rules for running a node (what many industry
observers today call “mining” or “transaction processing”) which govern those network participants
who create blocks and write transactions to the chain.44:

1. New transactions are broadcast to all nodes.

2. Each node collects new transactions into a block.
3. Each node works on finding a difficult PoW for its block.
4. When a node finds a PoW, it broadcasts the block to all nodes.
5. Nodes accept the block only if all transactions in it are valid and not already spent.
6. Nodes express their acceptance of the block by working on creating the next block in the
chain, using the hash of the accepted block as the previous hash.
7. Nodes rely on data from the longest chain to enter and exit the network freely.

For the system to remain functional, it is apparent there is no need to have a large number of
network nodes — provided there are good actors amongst the node operators.45 The original
Bitcoin implementation and associated discussions on forums indicate the network could run on
anywhere from ten computers to a large collection of networked devices; the network difficulty is
adjusted accordingly to enable a transaction network of nearly any size or hashpower.

3.3.8 Security
Before a transaction can be validated, it is checked by the other nodes for double spend. In the
case a double spend is confirmed, the transaction is deemed invalid. For Bitcoin, the earliest

41
Please refer to the following link for an explanation of a Merkle Tree if needed: https://www.geeksforgeeks.org/introduction-to-
merkle-tree/
42
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
43
Bitcoin Wiki. (n.d.). Bitcoin Community. Retrieved May 21, 2021, from https://en.Bitcoin.it/wiki/Genesis_block
44
Ibid
45
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
17
transaction is the one that counts. The only way an attacker could validate its own double spend
would be to harvest and maintain 51 percent of the network’s computing power and build a longer
chain. The mathematical probability of this occurrence is explained in the whitepaper. An attack of
this type could be subject to prosecution as all information surrounding the attack would be public
knowledge.

All public keys used in a transaction visible to anyone. However, it is up to each user to avoid
revealing information that can link oneself to a specific transaction and/or key. Users can create a
new key pair for each transaction to prevent being linked to a specific public address. However,
users do not have to exchange private information (such as name, age, location) to have a
transaction validated on the Bitcoin network.

SHA-25646 is a cryptographic hash function used heavily in Bitcoin. It is computationally infeasible

to decrypt a hashed message with computing power currently available. There are no current
threats to SHA-256.47 Even with quantum computing, SHA-256 can be increased to SHA-512 or
higher. The only known way to solve the hash is by brute force collisions. Therefore, although there
will be more computing power in the future, SHA algorithms can be scaled accordingly.

In the original Bitcoin protocol, the difficulty of solving the hash is changed every 2,016 blocks. This
adjustment is used to keep the block creation time at 10 minutes, even with advancing
technologies. This leads to an increase or decrease of difficulty approximately every two weeks in
the original Bitcoin protocol.48 The discovery of a solution to SHA hashing functions could be
detrimental as Bitcoin could be mined faster based on the computational efficiency of the solution.

3.4 Non-functional requirements

3.4.1 Integrity, transparency, and auditability
There are several non-functional requirements that become apparent through the analysis of the
whitepaper and forum posts. For the system to work efficiently and effectively it requires:

• Integrity amongst (some) of the node operators.

• Confidentiality and privacy of network participants upheld.
• Transparency and auditability within the ledger itself.
• Network reliability to process transactions.
• Network scaling to handle a large number of transactions.

46
Secure Hash Algorithms are a family of cryptographic hash functions published by the National Institute of Standards and Technology
(NIST) as a U.S. Federal Information Processing Standard (FIPS)
47
SHA-256 Cryptographic Hash Algorithm. (n.d.). Moveable Type Scripts. Retrieved on May 20, 2021, from https://www.movable-
type.co.uk/scripts/sha256.html
48
The difficulty adjustment algorithm period for BSV is a moving window of the last 144 blocks, a change inherited from the Bitcoin Cash
(BCH) implementation which resulted from a split of the BTC network in August 2017.
18
3.4.2 Availability
Provided there are other nodes to connect to, the ledger will remain readily available. Should there
be no nodes or only a single node, the ledger will become unavailable. If there is a significant drop-
in hash rate of the connected nodes there may be an instance where new transactions are at a
standstill, depending on the current hashing difficulty. This situation is highly unlikely due to the
profitability of mining Bitcoin.

The time required to confirm a Bitcoin transaction cannot be precisely predicted. Confirmation time
usually depends on the fee set by the transacting user, successful block generation time, and
propagation of the transactions through the network. If the user sets a fee that is too low, it risks not
getting pick up for several blocks, which delays the time for a transaction to be confirmed. Block
generation time varies depending on the difficulty of the network but is, on average, 10 minutes per
block.

3.4.3 Scalability
Scalability seems to be one of the biggest key performance indicators for measuring blockchain
performance. There are several known Satoshi posts that directly or indirectly raise the issue of being
able to handle large amounts of transactions via various business channels.49 Through forum posts
and responses, Satoshi regularly asserted the Bitcoin network would be able to scale appropriately
to sufficiently handle many types of unique use cases requiring the network and its underlying
infrastructure.

3.5 Implementation Attributes

The main attributes for the original Bitcoin protocol and network include block size, economic
incentives, and consensus mechanisms. These three attributes provide defining characteristics of
any given Bitcoin implementation, how that network will perform, and the functionality the network
provides. Ultimately that functionality determines how various applications utilize the power of a
particular blockchain network.

3.5.1 Block size

Block size is one of the main elements that allow for scalability of transaction volume and date
capacity on the network. A smaller block size means a limited number of transactions can happen.
If Bitcoin should be able to compete with the likes of Visa, as suggested by Satoshi, then it clearly
requires block size be adjusted higher over time.50 To supplement this, Satoshi mentions in an
email on the Metzdowd list that the potential size of a block could be nearly 100 gigabytes in the
future. This implies Satoshi had intentions for the block size to grow to that point.

Moreover, there are several use cases discussed on the Metzdowd emailing list, Bitcoin Forum, and
P2P Foundation forums. These include things like escrow services, pay-to-receive email, vending

49
Nakamoto, S. (2008). Metzdowd emailing list. https://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html
50
Nakamoto, S. (2010). Bitcoin Forum. https://Bitcointalk.org/index.php?topic=1347.msg15366 - msg15366
19
machines, web hosting, and software as a service (“SaaS”) payments. In effect, if there is a reason
for people to be transacting, the Bitcoin network should allow users to conduct that transaction.
Larger block sizes would be important to enable such additional use cases.

Block size is also important from the perspective of economic incentives that draw node operators
into running the distributed network. With a small block size, transaction fees will dramatically
increase over time as network use increases due to the limited number of transactions that can be
processed per block. Satoshi mentions several times that transactions on the Bitcoin network will
operate on low to no fees.51 Additionally, only after all the Bitcoin tokens have been minted and
distributed through block generation will the network rely on fees alone. To allow for this, and to
keep fees low, block size must be larger to allow for more transactions.

In addition to this block reward “subsidy” amount for blocks they win, node operators also receive
the aggregate of fees paid by all senders of transactions collected into the block they create. Node
operators must earn more in transaction fees as the number of fresh coins awarded in each block
reward decreases, both to keep fees low and to offset the reducing number of coins awarded in
the fixed “subsidy” for each block. This implies block size must be larger to allow for more
transactions and thus more transaction fees per block.

3.5.2 Economic incentives

Economic incentives stem from two elements of the protocol itself. First is the fact there will only
ever be 21 million bitcoin tokens — which were minted at the moment the Bitcoin system was
created — and “fresh” coins will be distributed over time with each new block until the supply of
coins is fully circulated. This leverages the well-known economic principle of scarcity. With a finite
amount of resources, the value of a resource in the future should be higher than the value of that
same resource today. In theory, scarcity should provide enough incentive for the first generation of
node operators to generate bitcoin.

To address the fact that the supply of block rewards will eventually end, Satoshi posited there
should be enough transactions (and thus transaction fees) within a single block to incentivize
mining in the long run.52 This implies a few things: First, Satoshi’s sentiment that transactions
should be low cost requires a large number of transactions be included in a single block. Second, it
would not be necessary to have a large number of node operators — only a few who are
specialized in mining at scale.

An important addition to the economic incentive of node operators relates to the cost of mining.53
Initially, mining was done on small CPUs running on personal computers. In a forum post, Satoshi
mentions trying to slow down the GPU54 race,55 as more people were attempting to win hashing

51
Nakamoto, S. (2010). Bitcoin Forum. https://Bitcointalk.org/index.php?topic=994.msg12168 - msg12168
52
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
53
Please refer to the following article for a brief explanation of Bitcoin Mining if needed: https://www.investopedia.com/tech/how-does-
bitcoin-mining-work/
54
GPU (Graphical Processing Unit) refers to a computer’s video card
55
Nakamoto, S. (2009). Bitcoint Forum. https://Bitcointalk.org/index.php?topic=12.msg54 - msg54
20
races and block rewards using more powerful computers. Now, most large node operators require
specialized hardware, such as ASIC processors that are purpose-built to mine Bitcoin.

Since Bitcoin requires PoW, the rewards from mining must remain profitable for the node
operators. In other words, hardware and electricity costs for miners directly affect profitably. As
more mining groups and mining pools compete for the block rewards more hash power is
required to win the right to mine the next block. Therefore, the average cost of equipment and
electricity for a miner to generate a block reward must be at least equal to or greater than the
block reward (fixed subsidiary amount + transaction fees).

3.5.3 Consensus mechanisms

A key feature that distinguishes Bitcoin from other blockchains is its consensus mechanisms.
Currently, there are blockchain projects that rely on alternate consensus systems such as proof of
stake (validation in proportion to the amount of currency owned and staked for the right to
validate transactions on the network) and proof of space (allocation of storage to solve a
challenge). Different consensus mechanisms affect which operators will join the distributed
network.

PoW has proven to be a secure system because of the intrinsic difficulty for someone to attack the
blockchain. As the whitepaper explains:

“To modify a past block, an attacker would have to record the proof of work
of the block and all blocks after it and then catch up with and surpass the
work of the honest nodes.”56

An attack on a PoW blockchain is not economically incentivized while the majority decision
(consensus) is represented by the longest chain, which has the greatest PoW invested in it.
Additionally, any attack would be publicly visible which implies that actions can be taken to
permanently stop attacks.

With PoW, the energy requirements can become larger if the network develops sufficient value to
attract more computing power willing to compete for the fixed subsidy block rewards and
transaction fees on the network. Additionally, node operator consensus allows for the forking of
the blockchain should the mutable rules change.

3.5.4 OpCodes and scripting

Bitcoin uses a scripting system for transactions. A script is a set of instructions sent along with each
transaction that describe how the next person can gain access to the bitcoin being sent.57 Scripting
provides a framework to change the parameters of what's required to access transferred bitcoins.

56 56
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
57
Bitcoin Wiki. (n.d.). Bitcoin Community. Retrieved May 21, 2021, from https://en.Bitcoin.it
21
For example, the scripting system could be used to require multiple private keys, combination of
several keys, or even that another transaction be completed first.58

OpCodes59 are the underlying operations that are used to build Bitcoin scripts. They are the
building blocks that allow a developer to create tools which allow users to have wallets, send
transactions, and essentially manage their accounts. In addition, OpCodes allow more technical
users the freedom to create systems that sit on top of the Bitcoin network.

OpCodes, and the scripts created, become a fundamental element in determining how different
Bitcoin implementations will function. For example, OP_PUSHDATA4 allowed users to push over
four gigabytes of data onto the stack through each Bitcoin transaction. This OpCode indicates
Satoshi clearly intended the Bitcoin network to handle large volumes of data — even pushing up to
four gigabytes of data per transaction (not even per block). OP_PUSHDATA4 could be called
multiple times, indicating a transaction could hypothetically be larger than four gigabytes.

3.6 Analysis of Bitcoin software v0.1.0 ALPHA

The Bitcoin software v0.1.0 ALPHA60 was developed on Windows and shared as an open-source
project on SourceForge. After installing the software, a user was required to download the entire
chain for validation. Once that was done, a user was able to connect to other nodes on the
network.

For transactions, a user was able to see all crediting and debiting transactions from the wallet
along with its description, status, and date. A user was able to send coins via IP for an online
transfer or via Bitcoin address if the recipient was not online. The sending via IP address was
removed in later versions due to many security risks. It was at the sender’s discretion whether to
include a transaction fee.

In order to mine (operate as a node), a user had to open the options tab and select the “Generate
Coins” option. The software would start to mine in the background of the computer using the CPU.

It was noted in the description above that the software was purely experimental and should not be
relied on for “actual financial transactions.”

There were several updates made to the software after v0.1.0. However, there were no substantial
changes to the Bitcoin software until Bitcoin v0.1.5. Here, a minimum transaction fee was set for
transactions of less than one cent to prevent DoS attacks.61 This was later removed as users found it

58
Ibid.
59
A full list of OpCodes for both BTC and BSV is available in Annex 2
60
See Annexes for timeline of source code changes up to v0.1.5
61
A Denial-of-service attack (DoS attack) is an attack with the objective to render a network unusable. In the case of Bitcoin, mass
spamming of free transactions in the early days of the network could make it unavailable for other users.
22
confusing. Satoshi mentioned in a reply on the Bitcoin Forum: “[w]e should always allow at least
some free transactions.”62

The Bitcoin v0.1.0 software was rather limiting. There was no command line implementation. If
changes were to be made, they needed to be hardcoded in the project files. There was no formal
bug tracking software; all bugs had to be reported to Satoshi via email or Bitcoin Forum. However,
the software allowed key functionalities as described in the whitepaper such as the sending /
receiving of Bitcoin, timestamped blocks, PoW with mining Bitcoin that utilized CPU power, and a
network with connected peers that required no personal data.

3.7 Satoshi’s original vision

From examining the whitepaper, forum posts, emails, and the source code for original Bitcoin
software, an image of Satoshi’s system begins to take shape. Satoshi describes, for the time, a
novel idea to a problem that had been around since the 1990s: How is the implementation of a
digital cash (without any trusted intermediaries) possible?63 Early digital cash projects had flaws
when it came to bad actors being able to double spend.

Satoshi’s vision for the Bitcoin project is best summarized by his first post on the Metzdowd
Forum64:

“I've been working on a new electronic cash system that's fully peer-to-peer,
with no trusted third-party.

The main properties:

Double-spending is prevented with a peer-to-peer network.
No mint or other trusted parties.
Participants can be anonymous.
New coins are made from Hashcash style proof-of-work.
The proof-of-work for new coin generation also powers the
network to prevent double-spending.”

Several core elements are required for the functionality of the Bitcoin system, as proposed in
Satoshi’s whitepaper. These include a distributed timestamp server, a PoW mechanism, and network
rules, which lay the foundation the Bitcoin software uses to turn the whitepaper into a proof of

62
Nakamoto, S. (2010). Bitcoin Forum. https://Bitcointalk.org/index.php?topic=994.msg12168 - msg12168
63
Ibid
64
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
23
concept. Additionally, the Bitcoin software65 provides the ability to store coins, send and receive
transactions, and verify payments.

Satoshi’s vision for Bitcoin outlines a distributed transaction network along with protocols for the
network to operate in a manner which alleviates the double spending problem. In addition, there
are clear indications from the original source materials this system should be able to scale to the
level of other large payment processors such as Visa.

This payment system had user data privacy at its forefront. From the whitepaper, forum posts, and
other writings, it is clear there is no intention to rely on a trusted third-party for transactions —
thus, eliminating the need for the traditional payment processors to collect potentially sensitive
data on its clients. It is important to note a trusted third-party refers to a traditional financial
institution such as a bank or payment processor. The system does not record an individual’s
identity, but the individuals will know who they are transacting with. For example, when Alice sends
bitcoin to Bob, Alice and Bob will know each other’s identity.

4. Comparing current implementations to Satoshi’s vision

The Bitcoin implementations that will be compared and referenced in this paper are those which
directly evolved from the Bitcoin implementation and subsequent forks of the Bitcoin software
code. Specifically, the choice was made to focus on the BTC and BSV implementations for the
following reasons:

• These contrast the key attributes in realizing Satoshi’s vision.

• BTC is currently the most popular and the most valuable coin.
• Capacity to identify impact of various development decisions of each implementation.

It is important to note there are several other Bitcoin implementations because of forks in the
original Bitcoin ledger. However, BTC and BSV provide us with two distinct implementations. BTC is
considered the original chain that was worked on by Satoshi until development was taken over by
the community.66 BSV was established with the clear intent to implement Bitcoin according to
Satoshi’s vision by restoring the original code and adhering to the design principles expressed in
the whitepaper, forum posts, and emails.67 While other implementations have sought to improve
the operations of the network, it was noted BSV has taken an approach to increase scalability
through larger block size limits and functionality through a restoration and extension of Script
functionality within its OpCodes.

Future considerations could include other implementations such as BCH, however, it is out
currently of the scope of this report. The level of effort required to fully review the BCH

65
Bitcoin was original distributed as a GUI based software which allowed users to create a node, and send/receive transactions
66
Community refers to the group of members of the Bitcoin Forum who participated in discussions, bug fixes etc.
67
Bitcoinsv for Developers. (n.d.). Bitcoinsv. Retrieved May 21, 2021, from https://Bitcoinsv.io/satoshis-vision/
24
implementation would add considerable time to the completion of this report. For the sake of a
comparison, and the fact that BSV is a fork of BCH, BSV provides an adequate counterpoint to the
development decisions from the BTC community.

4.1 Description of assessment framework

The assessment framework used within this section was developed for the collection and sorting of
research information. This was established to clarify the specification and intents for BTC and BSV
and compare these to the specification and identify limitations or opportunities for certain use
cases.

In the framework, lines of inquiry were identified in several areas including approach and concept
of Bitcoin, components, legality, privacy, design, external factors, resource usage, functionalities,
functional and non-functional requirements, associated risks and use cases. Each area was
subdivided into assessment procedures that were completed for BTC and BSV as well as the first
release of Bitcoin ALPHA v0.1.0. Each subcategory utilized resources available online including, but
not limited to, source code, wiki pages, original forum posts by Satoshi Nakamoto, original emails
written and received by Satoshi, and direct testing procedures of the different implementations.

4.2 Comparison of implementations

Table 2 below illustrates a summary of the key assessment areas against BTC and BSV current state
protocols:

Table 2 – Summary Results of Assessment Procedures

Area of Review Testing Criteria BTC 0.21 Review BSV 1.07 Review

(Met / Partially met / (Met / Partially met /

Not met) Not met)

Capabilities Double spend prevention Met Met

Independent of trusted Partially met Partially met

third parties

Incentive mechanism Partially met Met

Scalable transactions Not met Met

Functional Timestamp server Met Met

requirements
PoW mechanism Met Met

Network rules Met Met

25
 Area of Review Testing Criteria BTC 0.21 Review BSV 1.07 Review

(Met / Partially met / (Met / Partially met /

Not met) Not met)

Non-functional Security Met Met

Requirements
Reliability Partially met Met

Scalability Not met Partially met

Maintainability Partially met Partially met

Implementation Block size Not met Met

attributes
PoW mechanism Met Met

Energy requirements Partially met Met

Difficulty Met Met

OpCodes & Scripting Partially met Met

In some functions, BTC and BSV are similar. For example, both can allow users to transact without
relying on a third-party and prevent double spending leveraging similar timestamping, consensus
mechanisms, and encryption methods.

However, the original vision was meant to be an improved way of sending / receiving transactions
online with a lower probability of losing personal data while solving the major problem of double
spending. It sought to create a more efficient means of internet payments, including “small casual
transactions” by eliminating the needs for intermediaries.68 The original design intended Bitcoin to
be used for other functions (beyond mere payments) such as vending machines, paid emails, SaaS
products, website activations, etc.69 It is clear from the forum posts, writings, and community
discussions the Bitcoin protocol was intended to scale to allow for many forms of payments. This
includes macro-payments (i.e., settling an account at the end of the day) and micropayments (i.e.,
sending a small fee to access a service or send a text message).

Satoshi’s original vision of an electronic cash and payment system, as previously defined, implies
the biggest limitation of BTC is the small block size and growing fees to send transactions. In the
long-run, transaction fees are the economic incentive for node operators to process and add a new
block to the chain. Satoshi discussed a system that would always pick up the free transactions and
at least intended Bitcoin to run on a low fee model.70 If node operators on BTC are to have the

68
Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://nakamotoinstitute.org/static/docs/bitcoin.pdf
69
Nakamoto, S. (2009). Metzdowd email list. https://www.metzdowd.com/pipermail/cryptography/2009-January/015014.html
70
Nakamoto, S. (2010). Bitcoin Forum. https://Bitcointalk.org/index.php?topic=1347.msg15366 - msg15366
26
proper economic incentives in the long run, either fees for individual transactions will need to
dramatically increase — reducing (or outright preventing) the ability for micropayments — or
there must be a change to allow for increased transaction counts in a single block for there to be
enough smaller individual fees to justify processing the next block. In the long run, when mining is
completed, fees are the only economic incentive for node operators.

Considering these factors, BSV appears more aligned to the original intent of the payment system.
With an uncapped block size which can grow with market demand, a significantly largely number
of transactions can be included within each block, thereby allowing higher overall network
throughput. Miners could wait until a suitable number of transactions and their combined fees (i.e.,
the economic incentive) arrived until they started processing the next block. This would allow for
various payment sizes and the potential for some users to even process transactions with zero fees.

Another key difference between BTC and BSV lies within the details of the embedded development
script language implementations, or OpCodes, which allows for functionality such as smart
contracts to be developed within each system. BTC has fewer OpCodes implemented than BSV
(because many of those OpCodes were disabled or restricted along BTC’s history after Satoshi left
the project), and the functionality of some of the OpCodes are different than originally designed.71
In effect, this limits a developer’s ability to build complex functionality on top of the BTC protocol.
Some examples of OpCodes that are disabled in BTC and enabled in BSV are “OP_CAT,” “OP_MU,”
“OP_DIV,” though there are many more.

There are other OpCodes in BTC that have been modified, such as “OP_RETURN,” which
completely change the functionality of scripting. OP_RETURN was originally created by Satoshi to
end a script and skip the remaining instructions. This functionally no longer exists in BTC but is
present in BSV, which allows for more complex scripting as a result. Satoshi mentions that people
would develop a system suited for their own needs, but also the need for a system that would
allow for as many potential outcomes as possible. Smart contracts were envisioned and possible
with Bitcoin script and were built in from the start using the FORTH72-like script.

However, as mentioned previously, some OpCodes were disabled and changed over time. Coupled
with smaller block size, the potential for complex functionality to be developed was limited.
OpCodes such as OP_CHECKLOCKTIMEVERIFY and P2SH moved BTC away from the functionality
Satoshi had planned for the system.73 BSV re-enabled original Satoshi OpCodes; removed
restrictions (including data limits) on certain OpCodes; removed any developer-set default limit on
block sizes to remove limitations imposed by BTC developers; and made more complex and
functional tokens, smart contracts, and other advanced functionality possible. A complete
breakdown of all OpCodes is available in Annex 2.

71
Comparison of OpCodes can be seen in Annex 2
72
FORTH is a procedural, stack-based programming language and interactive environment designed by Charles H. "Chuck" Moore
73
See Annex 5 for a more detailed primer on the differences that moved BTC away from, and BSV closer to Satoshi’s original vision.
27
Table 2.1, below, represents a more detailed version of the differences in key assessments between
BTC and BSV..

28
Table 2.1 – Detailed results of assessment procedures

Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Double spend Review whether the The protocol leverages consensus Partially met Met
prevention sampled blockchain mechanisms using a timestamp server
The protocol leverages consensus The protocol leverages consensus
follows the design and longest chains to eliminate the
mechanisms using a timestamp server mechanisms using a timestamp server
principle of likelihood of double spending.
and longest chains to eliminate the and longest chains to eliminate the
eliminating double
likelihood of double spending. likelihood of double spending.
spending as described
in the Bitcoin There is one instance of a possible There are currently no known instances
whitepaper. double spend on January 21, 2021. of double spending.

Independent of Verify users can An entity can transact without the Partially met Partially met
trusted third independently reliance of any third-party.
If the entity does not mine the token, or Same as BTC.
parties purchase goods and
receive them as payment, they would
services without
have to rely on a third-party exchange to
resorting to paper or
purchase the specified token. Mining is
coin currency.
no longer reasonable for most
individuals as it is not possible without
Consider merchant
specialized equipment.
applications and
support infrastructure. An individual may have to rely on a
third-party (such as an exchange) to first
receive tokens.

29
Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Incentive Verify intermediate Node operators who successfully add a Partially met Met
mechanism nodes (i.e.., miners) new block should receive any new
As of the current date, miners are In the current state, based on several
receive a reward for tokens from the minting / reward
rewarded with 6.25 BTC per valid block blocks, there are free transactions that
successfully delivering process along with any transaction fees.
mined. Miners are also able to collect are processed.
transactions from the Once all-new coins have been
transaction fees associated with the
sender to the receiver. generated, there should be an
block.
Identify the incentive appropriately sized transaction fee to
design mechanisms allow for continued node operations Satoshi envisioned the subsidy portion of
(e.g., miner reward while still allowing for transactions fees the mining reward as the incentive for
and transaction fee- to be low. This implies a very large miners until there is no remaining fresh
setting mechanisms). number of transactions per successful bitcoin to be distributed with new block
block. While there is remaining bitcoin to rewards. That is when the transaction
be mined, “[w]e should always allow at fees would be mandatory in order to
least some free transactions.” maintain an incentive to mine.

In the current state, any transactions

without fees can starve in the memory
pool.

Scalable Can the sampled The network and block size should scale Not met Met
transactions blockchain scale dependent on network utilization. The
BTC is limited due to the fixed block size BSV no longer has any block size limit
accordingly to network should be able to compete with
of 1 MB and can only handle a maximum set as default by protocol developers.
support significant any existing large payment network in
of approximately seven transactions per BSV can maintain scalable transactions
volumes of terms of transaction volumes per day.
second. This imposes a maximum by increasing block size according to
transactions in a
number of transactions that can be network market forces.
timely manner if there
processed daily and would not facilitate
are significantly more
additional transaction volumes by
global adoption and
additional adoption.
usage?

30
Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Timestamp server Review the features in The protocol should require all Met Met
place for transactions and blocks to be
It was noted the protocol leverages Same as BTC.
timestamping blocks. timestamped. This is the basis for
timestamp server mechanisms to serve
Do these functions providing proof that transactions
as proof of existence.
match the protocol as happened in the past. This record should
detailed in the Bitcoin act as a source of truth as well as provide
whitepaper and forum the evidence of ownership.
posts (i.e., recording
transactions in the
wallet.dat)?

PoW mechanism Review whether the A consensus mechanism such as PoW Met Met
sampled blockchain must be in place to reduce the chances
It was noted the protocol uses the PoW Same as BTC.
follows the design of tokens being double spent.
design principal as described in the
principle of hash-
Bitcoin whitepaper.
based PoW as
described in the
Bitcoin whitepaper.

31
Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Network rules Identify the various The network should have a robust Met Met
peer-to-peer protocol in place. This includes how BTC uses P2P networking elements Same as BTC.
networking elements nodes communicate and propagate described in the whitepaper.
(e.g., node discovery, information across the network. Nodes
information entering the network should always rely
on the longest chain as the source of
propagation and
truth.
verification). In
addition to the core
The following rules should always be
decentralized applied:
blockchain 1. New transactions are broadcast
functionalities, identify to all nodes.
the mechanisms in 2. Each node collects new
place for ad hoc transactions into a block.
message passing and 3. Each node works on finding a
distributed difficult PoW for its block.
networking. 4. When a node finds a PoW, it
broadcasts the block to all
nodes.
5. Nodes accept the block only if
all transactions in it are valid
and not already spent.

Nodes express their acceptance of the

block by working on creating the next
block in the chain, using the hash of the
accepted block as the previous hash.

32
Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Security Determine which type A secure hash function should be in Met Met
of secure hash place. There should be opportunities to
It was noted the protocol used similar Same as BTC.
function is currently change the hashing function should
hashing algorithms such as SHA256.
implemented (e.g., there be a potential security flaw in the
Biggest security risks are associated with
SHA-256, SHA 512, implemented hashing function to allow
third-party services and not the protocol
etc.). Furthermore, are for the continued operations of the
itself.
there any IT network.
roadmaps or planned
upgrades to replace
the existing SHA?
Identify any potential
weaknesses / threats
to secure hash
function (e.g.,
quantum computing
or other cyber
security threats)?

Reliability Assessed through The network should always be available Partially met Met
interviews. and process all valid transactions
Free transactions can be ignored by Free transactions can and do occur
including free ones as there is still bitcoin
miners and may never get processed. within a BSV block.
to be mined.
The protocol does not have any history There is no known downtime of the
of being unavailable. network.

33
Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Scalability Do the current value- The network should be able to scale Not met Met
added activities align meet any demand in transactions and
The network is unable to scale with Theoretical unbounded number of
to the benefits as how users adopt the network.
adoption of the network due to limited transactions per block. This is restricted
intended by Satoshi
block size. There is a hard cap of seven by hardware and software limitations but
(e.g., efficiency,
transactions processed per second. This can theoretically grow with
eliminating a third-
restricts the usage of the network. improvements in technology over time.
party,
This would allow for mass adoption of
decentralization,
payment processing. This allows the
reduced errors,
network to be used in different use cases
increased efficiency,
such as a micropayment system.
scalability, etc.)?

Maintainability How well is the Depending on the scale, there should be Partially met Partially met
system maintained? a group or consortium leading the
There is a large community of There is an organized group of
Who are the parties ongoing development of the protocol.
developers contributing to the efforts of developers engaged by a global non-
responsible for Given this could grow to a global scale,
maintaining the ongoing development profit association-contributing to the
implementing there should be flexibility and clear
and support of the platform. efforts of maintaining the ongoing
changes and governance procedures to allow for
development and support of the node
upgrades over time? implementing critical path changes (ex: There are instances of groups of these
software and other infrastructure tools
Will it be reliable in addressing major security flaws). The developers not agreeing on a clear path
for the platform.
the long run? project shall always be open source. forward for development decisions (BTC
hard forks). There are some additional developers
and development groups around the
world also contributing infrastructure
tools to the network.

There is a dependency on a third-party

group of developers.

34
Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Block size Do the current value- Block size should scale based on network Not met Met
added activities align demand. There should be systems in
Block size has not scaled with the times The theoretical unbounded block size
to the benefits as place to prevent denial of service attacks
as it is still at 1 MB. This was set by aligns with Satoshi’s scaling vision.
intended by Satoshi by bad actors leveraging large block
Satoshi as a starting point. He envisioned
(e.g., efficiency, sizes.
the protocol to scale with the times.
eliminating a third-
party,
decentralization,
reduced errors,
increased efficiency,
scalability, etc.)?

Energy How much energy will Energy consumption should be left to Not met Met
requirements be required when node operators to determine. The overall
The overall energy requirements will The overall energy requirements will
running the energy requirements will vary depending
change as the system scales and change as the system scales and depend
distributed system? on the scale of the network.
depends on how many unique node on how many unique node operators
operators exist. See Annex 1 for a current exist
estimation of power consumption.
The required amount of energy per
The required amount of energy per transaction should be significantly lower
transaction will go up with difficulty as as the block size increases and more
the block size is capped. transactions can be processed by the
network with each block.
Specialized equipment is required to
mine block and power consumption has
increased with network size.

35
Criteria Assessment Satoshi’s Original Idea BTC V 0.21 Review BSV 1.0.7 Review
Procedure Description
(Met / Partially met / Not met) (Met / Partially met / Not met)

Difficulty Verify the projected Difficulty should adjust based on the Met Met
difficulty adjustment hashing power of the participating node
The protocol uses the same difficulty Same as BTC.
multiplier follows the operators.
formula as described by Satoshi in the
equation (i.e., blocks
It should be adjusted so new blocks of Bitcoin whitepaper.
since last adjustment
transactions happen approximately every
divided by time since
10 minutes.
last adjustment).

OpCodes & Verify there is a The scripting language and OpCodes Partially met Met
scripting robust scripting allow developers to create contracts.
Many OpCodes have been disabled BSV has re-enabled OpCodes which
language to enable
which prevent the creation of detailed allows for complex scripting and smart
developers to create
and complex smart contracts. contracts.
any style of
transaction.

36
5. Impact of Satoshi’s visions once fully realized
The original vision and long-term intentions were far beyond a mere electronic cash and payment
system. These elements are primarily provided by the script language and implementation details
of the stable, underlying protocol.

5.1 Electronic cash / payment system vision

In the years since its inception, Bitcoin has grown to include millions of currency holders,74 with
hundreds of thousands of active daily network users and approximately 300,000 transactions
processed per day. However, these numbers are extremely small compared to the billions of overall
daily transactions on other payment systems — for example, daily global credit card transactions
were estimated at over 1.01 billion in 2018.75

This incredibly large number of transactions processed globally also implies an incredible amount
of facilitation and control by financial institutions and intermediaries, as well as government and
industry regulatory overhead.

Bitcoin set out to make a global payment system by enabling individuals to transact directly with
each other via a secure, P2P and distributed technology solution, and allowing them to transmit
value over the network via data transfers. There is still a relatively small global number of people
who use Bitcoin as an electronic cash (currency) and payment system; that is in part because BTC
has not become the efficient system for electronic cash payments Satoshi envisioned. Bitcoin
payments are not widely accepted by merchants and other organizations. Moreover, the overall
combined value of the currency and transactions pales in comparison to the established fiat
systems. Several issues are standing in the way of Bitcoin becoming the predominant global
currency or payment system, including:

1. Volatility – Bitcoin’s value (in the form of BTC) is highly volatile and unpredictable. This makes
the value exchanged subject to change, sometimes on an hourly or daily basis. Balancing the
payment received for the value of the goods and services exchanged back to financial
accounting systems can be problematic.
2. Ease of use – Purchasing and using Bitcoin remains poorly understood within the general
population because it is more complex than traditional banking and payment systems.
3. General acceptability – In most areas of the world (with the exceptions noted), Bitcoin
(whether BSV or BTC) is not readily accepted as payment. Many merchants advertise it is a
promotion, but often are not adequately prepared with Bitcoin point of sale (“POS”) or
accounting systems to balance the currency.

74
https://www.buyBitcoinworldwide.com/how-many-Bitcoin-users/
75
https://www.cardrates.com/advice/number-of-credit-card-transactions-per-day-year/#worldwide

37
4. Scalability – The BTC network handles only approximately seven transactions per second and
transactions are not finalized for up to one hour in some instances, which makes high-volume
retail POS processing problematic. This pales in comparison other payment systems such as
Visa, which can process millions of transactions per second at POS (although arguably final
settlement occurs much slower).
5. Reputation / perception – Because of its linkages to criminal transactions, money laundering,
and many well-published exchange hacks, Bitcoin has a poor public reputation.

BSV seeks to address these and other issues to more fully realize the vision of Bitcoin as an
important electronic cash and payment system.

In developing nations where banking systems and currency are non-existent or unstable, there are
many examples of Bitcoin being used, including:

• Person-to-person payments via mobile Bitcoin wallets between people who have no access
to banking.
• Large payments from corporations to operations in emerging nations facilitated by Bitcoin
where traditional banking methods are slow and expensive.

In its complete form, the Bitcoin vision could have major implications for global financial
institutions, consumer behaviour, and investment strategies. Financial institutions which do not
recognize and embrace cryptocurrency and include Bitcoin in their strategic planning could face
elimination. Many banks, governments, investment houses, and other constituents in the financial
system have either already recognized this threat and put cryptocurrency plans and offerings
(including Bitcoin) in place or have contemplated adapting to emerging consumer behaviour in the
near future to ensure their long-term viability. This is often done within digital transformation
initiatives or innovation concept labs.

5.2 Other use case elements in the vision

In addition to the electronic cash vision, the Bitcoin system also included (and realized within the
code of its software) from the earliest days necessary elements to enable distributed data
applications. Bitcoin (along with its variants and most other digital currencies) use what is now
called blockchain technology — what the whitepaper describes as a distributed timestamp server
— which, when combined with the original Bitcoin protocol rules, provides the backbone for
enabling the vision.

At a high-level, blockchain architectures provide the following benefits / services that can be
leveraged within enterprise business applications:

• Cryptographic security
• Immutability
• Provenance
• Distributed data management
• Pseudonymity

38
 • Controlled transparency
• Auditability

The ability to leverage permissioned access to secured information stored in a publicly shared
blockchain ledger and the ability to leverage smart contracts and other data functions between
participants are the strongest functions that blockchain applications bring to the table for
developers of enterprise applications.

Depending on the business requirements and services required, developers have traditionally been
left with selecting a blockchain model from one of three choices:

• Public – Like the Bitcoin or Ethereum network for cryptocurrency applications

• Private / permissioned – Internally facing applications on infrastructure such as
Hyperledger’s Fabric
• Consortium blockchains – Developed and operated by a group of organizations, such as a
supply chain like IBM’s Food Trust consortium solution.

The overhead (upfront costs, governance challenges, etc.) of operating a private or consortium
blockchain puts these solutions beyond the reach of smaller corporations or start-ups and can
push project implementation times into many months or years.

From the earliest versions of Bitcoin, the script development language has enabled many of the
functions that support enterprise applications. There has been debate around whether Bitcoin
Script has sufficient functionality (or is Turing76 complete) to be considered general purpose for
creating these types of applications, and whether block size limitations (1 MB) may prevent the
broader use of Bitcoin to enable more functional applications.

The BSV platform has addressed these specific limitations and, in so doing, has provided the
capabilities required for enterprise blockchain application functionality, including:

1. Higher transaction throughput enabled by on-chain scaling due to removal of default block
size limit.
2. Lower transaction fees enabled by larger block sizes which eliminates congestion.
3. Non-transactional data that can be stored and manipulated on-chain due to the larger block
size and script language functionality.
4. BSV transactions are processed very quickly as there is a greater than 99 percent chance these
will be verified and included in the following block in the blockchain.
5. BSV Script language is Turing complete, which means the script can theoretically execute any
algorithm with limitless possibilities.
6. BSV offers the ability (through the scripting language enhancements) to create more complex
smart contracts supporting most conceivable asset types.
7. BSV offers very large data storage capabilities.

Turing complete means the scripting language could, in theory, be used to solve any computational
76

problem.

39
As a result, there are numerous developers using Bitcoin SV as an enterprise blockchain platform
for current applications involving transactional and traceability capabilities. A non-exhaustive list of
potential application use cases is provided below:

1. Data integrity and timestamping of documents / records

2. Supply chain applications, including end-to-end traceability applications and transactional
applications
3. Data storage and informational database applications
4. Many tokens and token-based applications
5. Micropayments for social media, online content, digital advertising, and online games
6. POS applications

The BSV blockchain has also allowed for a layered approach to enable off-chain components and
data to seamlessly integrate with the platform. This will enable easy-to-use interfaces between
what businesses and developers want to build and the more complicated Bitcoin network
mechanics that lie “under the hood.” Programs can leverage the money features, data structures,
and even each other with BSV. As the protocol enables a global ledger for anyone to work on the
potential for interoperability between applications is unprecedented. Programs no longer need to
operate solely on servers and their own databases, they can interact with other applications using
the same ledger.

Fully enabling this part of the vision provides a platform(s) that can satisfy enterprises needs with
massive scaling, a stable protocol, and a regulation-friendly ecosystem — powering blockchain
applications today and into the future.

6. Summary and conclusion

In late 2009 Satoshi proposed a new system to handle the transactions of a digital cash. This
concept has since grown to become a new type of standard for digital transactions. Like the early
versions of the internet, there have been many improvements and unique systems developed on
top of the Bitcoin protocol. There have even been competing protocols developed.

From proof of concept in early 2010 to present, Bitcoin has gone through its stages of evolution as
well. Currently, there are several competing Bitcoin implementations. This paper examined two of
those implementations: BTC and BSV. BTC and BSV both forge their own path in implementing the
Bitcoin transaction network as they see fit.

To summarize, Bitcoin, according to the writings and source material left behind by Satoshi, is type
of digital transaction network. At its core, the Bitcoin network provides mechanisms to allow for a
distributed transaction network to handle digital payments. Bitcoin has inherent features to greatly
reduce the chance of double spending, decrease the reliability on “trusted” third parties and
subsequently protect the privacy of those transacting on the network, and allow for the network to
scale to any size required by the participants of the network.

40
After examining BTC and BSV compared to the original vision set forth in the whitepaper, forum
posts, emails, and other writings by Satoshi, it is our opinion BSV is the implementation that
currently best represents what Satoshi originally intended. BSV has a theoretically unbound block
size, which allows payments to scale to the size of a Visa-like network without requiring an increase
in fees to meet the economic requirements of the node operators. BSV also provides more
functionality in terms of how developers can utilize the network for building their own transaction
systems on top of the Bitcoin protocol.

Regardless of which Bitcoin implementation the reader prefers - Bitcoin, the blockchain, and
distributed ledger technologies will continue to have measurable impacts on the future of
commerce, exchange, and trust in an increasingly decentralized and digitally dominant world.
Satoshi’s vision laid the foundation, but even he and his early acolytes would be amazed by the
potentially limitless ways this new technology can benefit society and enhance the financial
ecosystem.

41
Bibliography
Bitcoin Core integration/staging tree. Bitcoin Core [Source code]. Retrieved March 31, 2021, from
https://github.com/Bitcoin/Bitcoin

Bitcoin Difficulty historical chart. (n.d.). BitInfoCharts. Retrieved May 20, 2021, from
https://bitinfocharts.com/comparison/Bitcoin-difficulty.html#1y

Bitcoin Fork History. (n.d.). Unisot. Retrieved May 21, 2021, from https://unisot.com/why-Bitcoin-sv/

Bitcoinsv for Developers. (n.d.). Bitcoinsv. Retrieved May 21, 2021, from https://Bitcoinsv.io/

Bitcoin SV (Satoshi Vision). Bitcoinsv [Source code]. Retrieved March 31, 2021, from
https://github.com/Bitcoin-sv/Bitcoin-sv

Bitcoinsv Wiki. (n.d.). Bitcoinsv. Retrieved May 21, 2021, from https://wiki.Bitcoinsv.io

Bitcoin Wiki. (n.d.). Bitcoin Community. Retrieved May 21, 2021, from https://en.Bitcoin.it

Frankenfield, J. (2021, March 26). Mt.Gox. Investopia. https://www.investopedia.com/terms/m/mt-gox.asp

Frankenfield, J. (2021, May 14). Silk Road (Website). Investopia. https://www.investopedia.com/terms/s/silk-

road.asp

How Many Bitcoin Users Are There? (n.d.). Buy Bitcoin Worldwide. Retrieved May 27, 2021, from
https://www.buyBitcoinworldwide.com/how-many-Bitcoin-users/

Huang, R. (2019, April 26). How Bitcoin and WikiLeaks Saved Each Other. Forbes.
https://www.forbes.com/sites/rogerhuang/2019/04/26/how-Bitcoin-and-wikileaks-saved-each-
other/?sh=6b42079374a5

Munro, A. (2021, April 20). Exchanges that support BSV. Finder. https://www.finder.com/ca/how-to-buy-
Bitcoin-sv

Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.

https://nakamotoinstitute.org/static/docs/bitcoin.pdf

Nguyen, J. (n.d.). Bitcoin Association. Bitcoin SV: The Regulation-Friendly Bitcoin.

https://www.iadclaw.org/assets/1/7/6_Bitcoin_SV_The_Regulation-Friendly_Bitcoin.pdf

Node Explorer. (2021, May 20). Blockchair. https://blockchair.com/Bitcoin/nodes

Protocol. (n.d.). Lexico [Definition of protocol]. Retrieved May 27, 2021, from
https://www.lexico.com/definition/protocol

Sandberg, E. (2020, November 9). The Average Number of Credit Card Transactions Per Day & Year.
https://www.cardrates.com/advice/number-of-credit-card-transactions-per-day-year/#worldwide

Satoshi Nakamoto Institue. (n.d.). [Satoshi Nakamoto’s forum posts, email transcripts and original code].
https://nakamotoinstitute.org/

The cryptography Archives. (n.d.). Metzdowd. [Emailing list which Satoshi was a member of].
https://www.Metzdowd.com/pipermail/cryptography/

42
Annex

Annex 1: Energy calculations

The following describes the set of assumptions and calculations used to determine the energy
consumed by a SHA256 blockchain on a per block basis. This simple model provides an estimate;
further considerations are necessary to build a more complete model of a SHA256 blockchain’s
power consumption.

The following assumptions were made for these energy calculations:

• There are no additional resources required, such as heating, ventilation, and air
conditioning (“HVAC”), lighting, or other network devices requiring power. This assumption
is strong; however, individual cases will vary based on the size of a particular miner and
their geographic location. For example, mining operations in Brazil will require larger HVAC
systems than mining operations in northern Canada. To address this in the future,
additional research should go into determining the scale of mining operations and their
geographic locations.
• Miners are using the best technology available to them. This reduces the size of the set of
available mining equipment. For the purposes of this calculation, Bitmain’s Antminer S19j
that is capable of mining 90TH/s77 has been selected.
• This is meant to be a static calculation. It gives us a point in time estimate of the power
consumed for a given size of the network in question. An improvement on this would be to
examine it as a dynamic system which would allow for changes in network participation,
and changes in total network hash rate amongst other contributing factors.

To calculate the energy consumption per block the following variables were used:

Input Variable Fixed Inputs Outputs

► Current network hash rate ► Hash adjustment factor ► Total Mining Units
(“HR”), hash/sec (“HAF”) required (“TMU”)
► Mining Equipment Hash ► Block energy consumption
Power (“MHP”), hash/sec (“BEC”), watts/hour
► Mining Equipment Energy
(“MEE”), watts
► Average Block Time
(“ABT”), hours

77
Antminer s19j – 90TH/s. Bitmain. Retrieved on May 25, 2021, from
https://m.bitmain.com/product/00020210224195530399kqcF32sc06B9

43
Then, for any SHA256 blockchain:
𝐻𝑅
𝑇𝑀𝑈 =
𝑀𝐻𝑃 ∗ 𝐻𝐴𝐹
𝐵𝐸𝐶 = 𝐴𝐵𝑇 ∗ 𝑇𝑀𝑈 ∗ 𝑀𝐸𝐸

Block energy consumption can then be used to examine energy per transaction or scaled to and
hourly power consumption of the entire network.

Results78:

Bitcoin Alpha Bitcoin Core Bitcoin Satoshi’s Vision

(January 1, 2010) (May 1, 2021) (May 1, 2021)
HR = 7.255 MH/s HR = 136.27 EH/s HR = 765.31 PH
MHP*= 1 0.00145194 MH/ MHP = 0.00009 EH/s MHP = 0.09 PH
BEC = 64.96 kWh79 BEC = 0.47 GWh BEC = 0.0026 GWh
= 6.496x10-5GWh

*assuming CPU mining; intel i7-980X80

78
Hash rate from: https://bitinfocharts.com/comparison/hashrate-btc-bsv.html
79
Power usage from https://ark.intel.com/content/www/us/en/ark/products/47932/intel-core-i7-980x-processor-extreme-edition-12m-
cache-3-33-ghz-6-40-gt-s-intel-qpi.html
80
How profitable is mining. BetterHash. Retrieved on May 25, 2021, from https://www.betterhash.net/Intel(R)-Core(TM)-i7-CPU-X-980-
@-3.33GHz-mining-profitability-77699.html

44
 Annex 2: OpCodes
This annex compares the OpCodes between Bitcoin Satoshi’s Vision v1.04 and Bitcoin Core V 0.21.0.

Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
0 Yes OP_0, OP_FALSE An empty array of bytes is pushed Yes OP_0, OP_FALSE An empty array of bytes is pushed onto the stack. (This is not
onto the stack. (This is not a no-op: a no-op: an item is added to the stack.)
an item is added to the stack.)
1-75 Yes Pushdata Bytelength The next OpCode byte is data to be No NA The next OpCode byte is data to be pushed onto the stack.
pushed onto the stack.
76 Yes OP_PUSHDATA1 The next byte contains the number Yes OP_PUSHDATA1 The next byte contains the number of bytes to be pushed
of bytes to be pushed onto the onto the stack.
stack.
77 Yes OP_PUSHDATA2 The next two bytes contain the Yes OP_PUSHDATA2 The next two bytes contain the number of bytes to be pushed
number of bytes to be pushed onto onto the stack in little endian order.
the stack in little endian order.
Constants

78 Yes OP_PUSHDATA4 The next four bytes contain the Yes OP_PUSHDATA4 The next four bytes contain the number of bytes to be pushed
number of bytes to be pushed onto onto the stack in little endian.
the stack in little endian.
One byte has 8 bits. Therefore, 4 One byte has 8 bits. Therefore, 4 bytes have 32 bits. You can
bytes have 32 bits. You can represent binary base, octal base, hex base number systems.
represent binary base, octal base, The number system can represent (2^32) 4294967296
hex base number systems. The numbers. In the context of data this is about 4 gigabytes.
number system can represent
(2^32) 4294967296 numbers. In
the context of data this is about 4
gigabytes.
79 Yes OP_1NEGATE The number -1 is pushed onto the Yes OP_1NEGATE The number -1 is pushed onto the stack.
stack.

81
OpCodes for BSV retrieved on May 21, 2021, from https://wiki.bitcoinsv.io/index.php/Opcodes_used_in_Bitcoin_Script
82
OpCodes for BTC retrieved on May 21, 2021, from https://en.bitcoin.it/wiki/Script

45
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
81 Yes OP_1, OP_TRUE The number 1 is pushed onto the Yes OP_1, OP_TRUE The number 1 is pushed onto the stack.
stack.
82-96 Yes OP_2-OP_16 The number in the word name (2- Yes OP_2-OP_16 The number in the word name (2-16) is pushed onto the
16) is pushed onto the stack. stack.
97 Yes OP_NOP Does nothing. Yes OP_NOP Does nothing.
98 No OP_VER DISABLED Puts the version of the protocol Yes OP_VER THIS IS PART OF Transaction is invalid unless occurring in an unexecuted OP_IF
under which this transaction will be RESERVE WORDS branch
evaluated onto the stack. (This
OpCode is scheduled to be re-
enabled in the Chronicle update.)
99 Yes OP_IF If the top stack value is not FALSE, Yes OP_IF If the top stack value is not false, the statements are executed.
the statements between IF and The top stack value is removed.
ELSE are executed. If the top stack
value is FALSE, the statements
between ELSE and ENDIF are
executed. The top stack value is
Flow control

removed.
100 Yes OP_NOTIF If the top stack value is FALSE, the Yes OP_NOTIF If the top stack value is false, the statements are executed.
statements between IF and ELSE The top stack value is removed.
are executed.

If the top stack value is not FALSE

the statements between ELSE and
ENDIF are executed.

The top stack value is removed.

101 No OP_VERIF DISABLED If the top stack value is EQUAL to Yes OP_VERIF THIS IS PART OF Transaction is invalid even when occurring in an unexecuted
the version of the protocol under RESERVE WORDS OP_IF branch.
which this transaction will be
evaluated, the statements between
IF and ELSE are executed.

46
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
If the top stack value is NOT
EQUAL to the version of the
protocol under which this
transaction will be evaluated, the
statements between ELSE and
ENDIF are executed.

The top stack value is removed.

(This opcode is scheduled to be re-
enabled in the Chronicle update.)
102 No OP_VERNOTIF DISABLED If the top stack value is NOT Yes OP_VERNOTIF THIS IS PART OF Transaction is invalid even when occurring in an unexecuted
EQUAL to the version of the RESERVE WORDS OP_IF branch.
protocol under which this
transaction will be evaluated, the
statements between IF and ELSE
are executed.

If the top stack value is EQUAL to

the version of the protocol under
which this transaction will be
evaluated, the statements between
ELSE and ENDIF are executed.
The top stack value is removed.
(This OpCode is scheduled to be
re-enabled in the Chronicle
update.)
103 Yes OP_ELSE If the preceding OP_IF or Yes OP_ELSE If the preceding OP_IF or OP_NOTIF or OP_ELSE was not
OP_NOTIF or OP_ELSE was not executed, then these statements are and if the preceding
executed, then these statements OP_IF or OP_NOTIF or OP_ELSE was executed then these
are and if the preceding OP_IF or statements are not.
OP_NOTIF or OP_ELSE was

47
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
executed then these statements are
not.
104 Yes OP_ENDIF Ends an IF/ELSE block. All blocks Yes OP_ENDIF Ends an IF/ELSE block. All blocks must end, or the transaction
must end, or the transaction is is invalid. An OP_ENDIF without OP_IF earlier is also invalid.
invalid. An OP_ENDIF without a
prior matching OP_IF or OP_NOTIF
is also invalid.
105 Yes OP_VERIFY Marks transaction as invalid if top Yes OP_VERIFY Marks transaction as invalid if top stack value is not true. The
stack value is not true. The top top stack value is removed.
stack value is removed.
106 Yes OP_RETURN OP_RETURN can also be used to Yes OP_RETURN Marks transaction as invalid. Since Bitcoin 0.9, a standard way
create "False Return" outputs with a of attaching extra data to transactions is to add a zero-value
scriptPubKey consisting of output with a scriptPubKey consisting of OP_RETURN
OP_FALSE OP_RETURN followed by followed by data. Such outputs are provably unspendable and
data. Such outputs are probably specially discarded from storage in the UTXO set, reducing
unspendable and should be given a their cost to the network. Since 0.12, standard relay rules allow
value of zero Satoshis. These a single output with OP_RETURN, that contains any sequence
outputs can be pruned from of push statements (or OP_RESERVED[1]) after the
storage in the UTXO set, reducing OP_RETURN provided the total scriptPubKey length is at most
its size. Currently the BitcoinSV 83 bytes.
network supports multiple FALSE
RETURN outputs in a given
transaction with each one capable
of holding up to 100 kB of data.
After the Genesis upgrade in 2020
miners will be free to mine
transactions containing FALSE
RETURN outputs of any size.
107 Yes OP_TOALTSTACK Puts the input onto the top of the Yes OP_TOALTSTACK Puts the input onto the top of the alt stack. Removes it from
Stack

alt stack. Removes it from the main the main stack.

stack.

48
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
108 Yes OP_FROMALTSTACK Puts the input onto the top of the Yes OP_FROMALTSTACK Puts the input onto the top of the main stack. Removes it
main stack. Removes it from the alt from the alt stack.
stack.
109 Yes OP_2DROP Removes the top two stack items. Yes OP_2DROP Removes the top two stack items.
110 Yes OP_2DUP Duplicates the top two stack items. Yes OP_2DUP Duplicates the top two stack items.
111 Yes OP_3DUP Duplicates the top three stack Yes OP_3DUP Duplicates the top three stack items.
items.
112 Yes OP_2OVER Copies the pair of items two spaces Yes OP_2OVER Copies the pair of items two spaces back in the stack to the
back in the stack to the front. front.
113 Yes OP_2ROT The fifth and sixth items back are Yes OP_2ROT The fifth and sixth items back are moved to the top of the
moved to the top of the stack. stack.
114 Yes OP_2SWAP Swaps the top two pairs of items. Yes OP_2SWAP Swaps the top two pairs of items.
115 Yes OP_IFDUP If the top stack value is not 0, Yes OP_IFDUP If the top stack value is not 0, duplicate it.
duplicate it.
116 Yes OP_DEPTH Counts the number of stack items Yes OP_DEPTH Puts the number of stack items onto the stack.
onto the stack and places the value
on the top.
117 Yes OP_DROP Removes the top stack item. Yes OP_DROP Removes the top stack item.
118 Yes OP_DUP Duplicates the top stack item. Yes OP_DUP Duplicates the top stack item.
119 Yes OP_NIP Removes the second-to-top stack Yes OP_NIP Removes the second-to-top stack item.
item.
120 Yes OP_OVER Copies the second-to-top stack Yes OP_OVER Copies the second-to-top stack item to the top.
item to the top.
121 Yes OP_PICK The item n back in the stack is Yes OP_PICK The item n back in the stack is copied to the top.
copied to the top.
122 Yes OP_ROLL The item n back in the stack is Yes OP_ROLL The item n back in the stack is moved to the top.
moved to the top.
123 Yes OP_ROT The top three items on the stack Yes OP_ROT The 3rd item down the stack is moved to the top.
are rotated to the left.

49
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
124 Yes OP_SWAP The top two items on the stack are Yes OP_SWAP The top two items on the stack are swapped.
swapped.

125 Yes OP_TUCK The item at the top of the stack is Yes OP_TUCK The item at the top of the stack is copied and inserted before
copied and inserted before the the second-to-top item.
second-to-top item.
126 Yes OP_CAT Concatenates two strings. No OP_CAT DISABLED Concatenates two strings.
127 Yes OP_SPLIT Split byte sequence x at position n. No OP_SUBSTR DISABLED Returns a section of a string. Disabled.
Data manipulation

128 Yes OP_NUM2BIN Converts numeric value a into byte No OP_LEFT DISABLED Keeps only characters left of the specified point in a string.
sequence of length b. Disabled.
129 Yes OP_BIN2NUM Converts byte sequence x into a No OP_RIGHT DISABLED Keeps only characters right of the specified point in a string.
numeric value. Disabled.
130 Yes OP_SIZE Pushes the string length of the top Yes OP_SIZE Pushes the string length of the top element of the stack
element of the stack (without (without popping it).
popping it).
131 Yes OP_INVERT Flips all of the bits in the input. No OP_INVERT DISABLED Flips all of the bits in the input.
132 Yes OP_AND Boolean and between each bit in No OP_AND DISABLED Boolean and between each bit in the inputs.
the inputs.
133 Yes OP_OR Boolean or between each bit in the No OP_OR DISABLED Boolean or between each bit in the inputs.
Bitwise logic

inputs.
134 Yes OP_XOR Boolean exclusive or between each No OP_XOR DISABLED Boolean exclusive or between each bit in the inputs.
bit in the inputs.
135 Yes OP_EQUAL Returns 1 if the inputs are exactly Yes OP_EQUAL Return 1 if the inputs are exactly equal, 0 otherwise.
equal, 0 otherwise.
136 Yes OP_EQUALVERIFY Same as OP_EQUAL, but runs Yes OP_EQUALVERIFY Same as OP_EQUAL, but runs OP_VERIFY afterward.
OP_VERIFY afterward.
139 Yes OP_1ADD 1 is added to the input. Yes OP_1ADD 1 is added to the input.
Arithmetic

140 Yes OP_1SUB 1 is subtracted from the input. Yes OP_1SUB 1 is subtracted from the input.
141 No OP_2MUL DISABLED The input is multiplied by 2. (This No OP_2MUL DISABLED The input is multiplied by 2. Disabled.
opcode is scheduled to be re-
enabled in the Chronicle update.)

50
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
142 No OP_2DIV DISABLED The input is divided by 2. (This No OP_2DIV DISABLED The input is divided by 2. Disabled.
opcode is scheduled to be re-
enabled in the Chronicle update.)
143 Yes OP_NEGATE The sign of the input is flipped. Yes OP_NEGATE The sign of the input is flipped.
144 Yes OP_ABS The input is made positive. Yes OP_ABS The input is made positive.
145 Yes OP_NOT If the input is 0 or 1, it is flipped. Yes OP_NOT If the input is 0 or 1, it is flipped. Otherwise, the output will be
Otherwise, the output will be 0. 0.
146 Yes OP_0NOTEQUAL Returns 0 if the input is 0. Yes OP_0NOTEQUAL Returns 0 if the input is 0. Otherwise 1.
Otherwise 1.
147 Yes OP_ADD a is added to b. Yes OP_ADD a is added to b.
148 Yes OP_SUB b is subtracted from a. Yes OP_SUB b is subtracted from a.
149 Yes OP_MUL a is multiplied by b. No OP_MUL DISABLED a is multiplied by b.
150 Yes OP_DIV a is divided by b. No OP_DIV DISABLED a is divided by b.
151 Yes OP_MOD Returns the remainder after No OP_MOD DISABLED Returns the remainder after dividing a by b.
dividing a by b.
152 Yes OP_LSHIFT Logical left shift b bits. Sign data is No OP_LSHIFT DISABLED Logical left shift b bits. Sign data is discarded.
discarded.
153 Yes OP_RSHIFT Logical right shift b bits. Sign data No OP_RSHIFT DISABLED Logical right shift b bits. Sign data is discarded.
is discarded.
154 Yes OP_BOOLAND If both a and b are not 0, the Yes OP_BOOLAND If both a and b are not 0, the output is 1. Otherwise 0.
output is 1. Otherwise 0.
155 Yes OP_BOOLOR If a or b is not 0, the output is 1. Yes OP_BOOLOR If a or b is not 0, the output is 1. Otherwise 0.
Otherwise 0.
156 Yes OP_NUMEQUAL Returns 1 if the numbers are equal. Yes OP_NUMEQUAL Returns 1 if the numbers are equal. Otherwise 0.
Otherwise 0.
157 Yes OP_NUMEQUALVERIFY Same as OP_NUMEQUAL, but runs Yes OP_NUMEQUALVERIFY Same as OP_NUMEQUAL, but runs OP_VERIFY afterward.
OP_VERIFY afterward.
158 Yes OP_NUMNOTEQUAL Returns 1 if the numbers are not Yes OP_NUMNOTEQUAL Returns 1 if the numbers are not equal. Otherwise 0.
equal. Otherwise 0.

51
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
159 Yes OP_LESSTHAN Returns 1 if a is less than b. Yes OP_LESSTHAN Returns 1 if a is less than b. Otherwise 0.
Otherwise 0.
160 Yes OP_GREATERTHAN Returns 1 if a is greater than b. Yes OP_GREATERTHAN Returns 1 if a is greater than b. Otherwise 0.
Otherwise 0.
161 Yes OP_LESSTHANOREQUAL Returns 1 if a is less than or equal Yes OP_LESSTHANOREQUAL Returns 1 if a is less than or equal to b. Otherwise 0.
to b. Otherwise 0.
162 Yes OP_GREATERTHANOREQUAL Returns 1 if a is greater than or Yes OP_GREATERTHANOREQUAL Returns 1 if a is greater than or equal to b. Otherwise 0.
equal to b. Otherwise 0.
163 Yes OP_MIN Returns the smaller of a and b. Yes OP_MIN Returns the smaller of a and b.
164 Yes OP_MAX Returns the larger of a and b. Yes OP_MAX Returns the larger of a and b.
165 Yes OP_WITHIN Returns 1 if x is within the specified Yes OP_WITHIN Returns 1 if x is within the specified range (left-inclusive).
range (left-inclusive). Otherwise 0. Otherwise 0.
166 Yes OP_RIPEMD160 The input is hashed using RIPEMD- Yes OP_RIPEMD160 The input is hashed using RIPEMD-160.
160.
167 Yes OP_SHA1 The input is hashed using SHA-1. Yes OP_SHA1 The input is hashed using SHA-1.
168 Yes OP_SHA256 The input is hashed using SHA-256. Yes OP_SHA256 The input is hashed using SHA-256.
169 Yes OP_HASH160 The input is hashed twice: first with Yes OP_HASH160 The input is hashed twice: first with SHA-256 and then with
SHA-256 and then with RIPEMD- RIPEMD-160.
160.
170 Yes OP_HASH256 The input is hashed two times with Yes OP_HASH256 The input is hashed two times with SHA-256.
Cryptography

SHA-256.
171 Yes OP_CODESEPARATOR All of the signature checking words Yes OP_CODESEPARATOR All of the signature checking words will only match signatures
will only match signatures to the to the data after the most recently executed
data after the most recently OP_CODESEPARATOR.
executed OP_CODESEPARATOR.
172 Yes OP_CHECKSIG The entire transaction's outputs, Yes OP_CHECKSIG The entire transaction's outputs, inputs, and script (from the
inputs, and script (from the most most recently executed OP_CODESEPARATOR to the end) are
recently executed hashed. The signature used by OP_CHECKSIG must be a valid
OP_CODESEPARATOR to the end) signature for this hash and public key. If it is, 1 is returned.
are hashed. The signature used by Otherwise 0.
OP_CHECKSIG must be a valid

52
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
signature for this hash and public
key. If it is, 1 is returned. Otherwise
0.
173 Yes OP_CHECKSIGVERIFY Same as OP_CHECKSIG, but Yes OP_CHECKSIGVERIFY Same as OP_CHECKSIG, but OP_VERIFY is executed afterward.
OP_VERIFY is executed afterward.
174 Yes OP_CHECKMULTISIG Compares the first signature Yes OP_CHECKMULTISIG Compares the first signature against each public key until it
against each public key until it finds finds an ECDSA match. Starting with the subsequent public
an ECDSA match. Starting with the key, it compares the second signature against each remaining
subsequent public key, it compares public key until it finds an ECDSA match. The process is
the second signature against each repeated until all signatures have been checked or not
remaining public key until it finds enough public keys remain to produce a successful result. All
an ECDSA match. The process is signatures need to match a public key. Because public keys
repeated until all signatures have are not checked again if they fail any signature comparison,
been checked or not enough public signatures must be placed in the scriptSig using the same
keys remain to produce a order as their corresponding public keys in the scriptPubKey
successful result. All signatures or redeemScript. If all signatures are valid, 1 is returned.
need to match a public key. Otherwise 0. Due to a bug, one extra unused value is
Because public keys are not removed from the stack.
checked again if they fail any
signature comparison, signatures
must be placed in the scriptSig
using the same order as their
corresponding public keys in the
scriptPubKey or redeemScript. If all
signatures are valid, 1 is returned.
Otherwise 0. Due to a bug, an extra
unused value (x) is removed from
the stack. Script spenders must
account for this by adding a junk
value (typically zero) to the stack.

53
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
175 Yes OP_CHECKMULTISIGVERIFY Same as OP_CHECKMULTISIG, but Yes OP_CHECKMULTISIGVERIFY Same as OP_CHECKMULTISIG, but OP_VERIFY is executed
OP_VERIFY is executed afterward. afterward.

177 Yes OP_NOP2 (previously NO OPERATION evaluation process Yes OP_CHECKLOCKTIMEVERIFY Marks transaction as invalid if the top stack item is greater
OP_CHECKLOCKTIMEVERIFY) for UTXOs that predate Genesis: (previously OP_NOP2) than the transaction's nLockTime field, otherwise script
Mark transaction as invalid if the evaluation continues as though an OP_NOP was executed.
top stack item is greater than the Transaction is also invalid if the stack is empty; the top stack
Used NOP opcode identifiers

transaction's nLockTime field, item is negative; the top stack item is greater than or equal to
otherwise script evaluation 500.000.000 while the transaction's nLockTime field is less
continues as though an OP_NOP than 500.000.000, or vice versa; or the input's nSequence field
was executed. Transaction is also is equal to 0xffffffff. The precise semantics are described in BIP
invalid if: the stack is empty; the 0065.
top stack item is negative; the top
stack item is greater than or equal
to 500,000,000 while the
transaction's nLockTime field is less
than 500,000,000, or vice versa; or
the input's nSequence field is equal
to 0xffffffff. The precise semantics
are described in BIP 0065.

54
Group Op- Used in BSV Script OpCodes81 Descriptions Used in BTC Script OpCodes82 Descriptions
Codes BSV BTC
Language Language
178 Yes OP_NOP3 (previously NO OPERATION evaluation process Yes OP_CHECKSEQUENCEVERIFY Marks transaction as invalid if the relative lock time of the
OP_CHECKSEQUENCEVERIFY) for UTXOs that predate Genesis: (previously OP_NOP3) input (enforced by BIP 0068 with nSequence) is not equal to
Mark transaction as invalid if the or longer than the value of the top stack item. The precise
relative lock time of the input semantics are described in BIP 0112.
(enforced by BIP 0068 with
nSequence) is not equal to or
longer than the value of the top
stack item. The precise semantics
are described in BIP 0112.
253 Yes OP_PUBKEYHASH Represents a public key hashed Yes OP_PUBKEYHASH Represents a public key hashed with OP_HASH160.
Pseudo-words

with OP_HASH160.
254 Yes OP_PUBKEY Represents a public key compatible Yes OP_PUBKEY Represents a public key compatible with OP_CHECKSIG.
with OP_CHECKSIG.
255 Yes OP_INVALIDOPCODE Matches any OpCode that is not Yes OP_INVALIDOPCODE Matches any OpCode that is not yet assigned.
yet assigned.
80 Yes OP_RESERVED Transaction is invalid unless Yes OP_RESERVED Transaction is invalid unless occurring in an unexecuted OP_IF
occurring in an unexecuted OP_IF branch.
branch.
Reserved words

137 Yes OP_RESERVED1 Transaction is invalid unless Yes OP_RESERVED1 Transaction is invalid unless occurring in an unexecuted OP_IF
occurring in an unexecuted OP_IF branch.
branch.
138 Yes OP_RESERVED2 Transaction is invalid unless Yes OP_RESERVED2 Transaction is invalid unless occurring in an unexecuted OP_IF
occurring in an unexecuted OP_IF branch.
branch.
176, Yes OP_NOP1, OP_NOP4-OP_NOP10 The word is ignored. Does not Yes OP_NOP1, OP_NOP4- The word is ignored. Does not mark transaction as invalid.
179-185 mark transaction as invalid. OP_NOP10

55
Annex 3: Source code timeline
The following table provides a timeline of the development and release of the Bitcoin software from v 0.1.0 to v 0.1.5. Included are key
contributors, a context of where these changes came from, and insights on how this relates to Satoshi’s Nakamoto’s vision for the Bitcoin
network.
Bitcoin version Key contributors Summary Context Source code update Insights on the true Satoshi vision Link to forum Forum post date
post
Satoshi Nakamoto; Satoshi posted that he had been working on a Satoshi made his first There was no source code at this Satoshi stated: 2008-10-31
new electronic cash system that is fully peer- post with his time.
to-peer, with no trusted third-party. He linked whitepaper. "The main properties:
his whitepaper for the first time and described
Double-spending is prevented
some main properties.
with a peer-to-peer network. https://www.metzd
owd.com/pipermai
l/cryptography/20
No mint or other trusted parties. 08-
Participants can be anonymous. October/014810.ht
ml
New coins are made from
Hashcash style PoW.

The PoW for new coin generation

also powers the network to
prevent double-spending."
Satoshi Nakamoto; Someone stressed the plausibility of handling James was questioning There was no source code at this Satoshi envisioned a network that 2008-11-02
James A. Donald; immense number of transactions with Satoshi's the scalability of time. could indeed handle as many
proposed electronic cash system. Satoshi Satoshi's idea with transactions as Visa. https://www.metzd
speaks to the possible number of transactions a regards to double owd.com/pipermai
l/cryptography/20
network he is proposing could handle. He says: spending, the number 08-
"If the network were to get that big, it would of transactions, and November/014815.
take several years, and by then, sending 2 HD bandwidth. html
movies over the Internet would probably not
seem like a big deal." He refers to his idea of a
p2p e-cash system.

Satoshi Nakamoto; Satoshi is not worried about the risk of zombie Satoshi and several There was no source code at this Satoshi speaks about the large 2008-11-03
James A. Donald; farms overpowering the network. He even others are discussing th time. farms. He does not directly talk
https://www.metzd
John Levine; suggests zombie farms may contribute to the threat of someone about centralization, but does owd.com/pipermai
Ray Dillinger; network and generate bitcoin instead. Satoshi having more CPU powr acknowledge large mining farms l/cryptography/20
also explains how even if there were to be a than the rest of the were a possibility. 08-
honest nodes. November/014818.
double spend, someone would only be able to html
"take money back he himself spent, like
bouncing a check." He also suggests someone
would make more by generating bitcoin than
attacking the system.

Satoshi Nakamoto; "Governments are good at cutting off the No one knows the There was no source code at this Satoshi envisioned a pure peer- 2008-11-06
https://www.metzd
Anonymous; heads of a centrally controlled networks like context of this reply as time. to-peer network. owd.com/pipermai
Napster, but pure P2P networks like Gnutella the conversation was ot l/cryptography/20
and Tor seem to be holding their own. " made public. 08-
November/014823.
html

56
Bitcoin version Key contributors Summary Context Source code update Insights on the true Satoshi vision Link to forum Forum post date
post
Satoshi Nakamoto; Satoshi talks about how the system will handle Ray had doubts about There was no source code at this Satoshi suggests creating a constant https://www.metzd 2008-11-08
Ray Dillinger; increasing hardware speed. He states the the scaling of the time. rate at which coins are initially owd.com/pipermai
difficulty of generating coins will proportionally network from a distributed "seems like the best l/cryptography/20
08-
increase keeping the production constant. And technological standpoint. formula." Difficulty of generating November/014831.
that is why there is a known number of Bitcoins will move in parallel with the html
Bitcoins created every year in the future. time and advancement of computing
power.

Satoshi Nakamoto; Satoshi explains that even if transactions do not Satoshi is answering a There was no source code at this Satoshi viewed the possibility of 2008-11-08
Hal Finney; get added to a block immediately it will be held lot of Hal Finney's time. Bitcoin being used for buying
in a working set until it is added to a block. He questions regarding goods and "immediately" being https://www.metzd
also suggests the receiver of transactions will the system. able to re-spend bitcoin. However, owd.com/pipermai
l/cryptography/20
normally need to wait for "perhaps" an hour or the receiver of said bitcoin "should 08-
more to allow the verification of a transaction wait before taking action such as November/014832.
that has been spent on two different branches. shipping goods." To ensure there is html
He then continued to explain the concept of enough time to validate the
the longest valid chain and how transactions transaction.
are dependent on only other valid transactions
or transactions in the same block.

Satoshi Nakamoto; Satoshi explains the PoW chain concept. Satoshi answering There was no source code at this N/A 2008-11-08
time. https://www.metzd
James A. Donald; "Once a transaction is hashed into a link that is questions. owd.com/pipermai
a few links back in the chain, it is firmly etched l/cryptography/20
into the global history." 08-
November/014833.
html

Satoshi Nakamoto; Satoshi explains to James that Bitcoin Satoshi answered There was no source code at this Satoshi suggests adding frees to 2008-11-09
time. https://www.metzd
James A. Donald; does not require inflation. questions regarding the blocks as incentives for the owd.com/pipermai
inflation issue. PoW concept. l/cryptography/20
08-
November/014842.
html

Satoshi Nakamoto; If there are multiple double-spent versions of Satoshi continuing to There was no source code at this Target time between blocks of 10 2008-11-10
James A. Donald; same transaction, only one will become valid. explain exact details. time. minutes. Every block includes its
Target time between blocks will probably be 10 creation time. If the time is off by
minutes. Every block includes its creation time. If more than 36 hours, other nodes
https://www.metzd
the time is off by more than 36 hours, other won't work on it. If the timespan over owd.com/pipermai
nodes won't work on it. If the timespan over the the last 6*24*30 blocks is less than 15 l/cryptography/20
last 6*24*30 blocks is less than 15 days, blocks days, blocks are being generated too 08-
are being generated too fast and the proof of fast and the proof-of-work difficulty November/014843.
html
work difficulty doubles. Everyone does the same doubles. Everyone does the same
calculation with the same chain data, so they all calculation with the same chain data,
get the same result at the same link in the chain." so they all get the same result at the
Satoshi explains that Bitcoin can validate same link in the chain. Transactions
transactions much faster than cheques and credit are irreversible in one to two hours.
cards.

Satoshi Nakamoto; Satoshi gives Byzantine General’s Problem Satoshi gives Byzantine There was no source code at this N/A 2008-11-13
time. https://www.metzd
Hal Finney; explanation to James. Satoshi concludes General’s Problem owd.com/pipermai
that the PoW chain is how everything is explanation. l/cryptography/20
James A. Donald; distributed and synchronized. 08-
November/014849.
html

57
 Bitcoin version Key contributors Summary Context Source code update Insights on the true Satoshi vision Link to forum Forum post date
post
Satoshi Nakamoto; Satoshi states it is only important to have a Satoshi confirms / There was no source code at this Bitcoin is very attractive to the https://www.metzd 2008-11-14
Hal Finney; pending transaction pool for the current best clarifies statements made time. libertarian viewpoint. Reorganizations owd.com/pipermai
branch. When new blocks arrive, they remove by everyone else. of the branches are rare. Bitcoin will l/cryptography/20
08-
James A. Donald; transactions from that pool. If a different use TCP transmissions. Blocks must November/014853.
branch becomes longer there is a re- propagate much faster than it takes html
organization, which he states would be rare. to generate them.
Networks broadcasts are reliable with TCP
transmissions and a retry mechanism.
Satoshi Nakamoto; Buyers are the only member digitally signing Satoshi confirms / There was no source code at this "The PoW is a Hashcash style SHA- 2008-11-14
https://www.metzd
Ray Dillinger; transactions. All ties in chains of equal length clarifies statements made time. 256 collision finding." owd.com/pipermai
James A. Donald; are broken by keeping the earliest one by everyone else. l/cryptography/20
received. All double spends are immediately 08-
rejected. Chain domination is purely based on November/014858.
html
proportional share of CPU power.

Bitcoin Pre-Release Satoshi Nakamoto; New key pair for every transaction. Bitcoin is Satoshi confirms / There was no source code at this New key pair for every transaction. 2008-11-15
Ray Dillinger; pseudonymous in the sense of the next action clarifies statements made time. Bitcoin is pseudonymous in the sense
on a coin can be identified as being from the by Ray. of the next action on a coin can be
owner of that coin. Credentials that establish identified as being from the owner of
someone as real is the ability to provide CPU that coin. Credentials that establish
power. Satoshi also clarifies how people could someone as real is the ability to
prevent being scammed by double spending provide CPU power.
(waiting 2 minutes).

https://www.metzd
owd.com/pipermail
/cryptography/200
8-
November/014860.
html

58
Bitcoin version Key contributors Summary Context Source code update Insights on the true Satoshi vision Link to forum Forum post date
post
Satoshi Nakamoto; Satoshi was clarifying more details about his Satoshi sent SOME of Main header file: N/A 2008-11-17
James A. Donald; idea and stated the source code would be the source code files to
coming soon. He also stated he would send James (main files) and • The minimal PoW
the main files per people's request. possibly others. difficulty was not set yet
(it was set to 40 in
commented code).
• Transactions contain
multiple inputs and
outputs (vector of input
transactions and vector of
output transactions)
• Presence of other
connected nodes —
presence of a Merkle
branches — each block
contains hash of the
https://www.met
previous block and hash zdowd.com/pip
of the Merkle root ermail/cryptogra
• Contains Merkle tree in the phy/2008-
November/0148
memory — "Nodes collect 63.html
new transactions into a
block, hash them into a hash
tree, and scan through
nonce values to make the
block's hash satisfy PoW
requirements. When they
solve the PoW, they
broadcast the block to
everyone and the block is
added to the time chain.
The first transaction in the
block is a special one that
creates a new coin owned
by the creator of the block."
• - "The time chain is a tree-
shaped structure starting with
the genesis block at the root,
with each block potentially

Satoshi Nakamoto; Satoshi explains Bitcoin IS NOT anonymous, Satoshi explaining how No source code update. Bitcoin IS NOT anonymous, it is 2008-11-17
Nicolas Williams; it is pseudonymous. To detect a double a double spend is pseudonymous. To detect a double, https://www.met
zdowd.com/pip
spend, the network DOES NOT need to identified. spend, the network DOES NOT ermail/cryptogra
come to a final consensus, only an need to come to a final consensus, phy/2008-
November/0148
approximate consensus. only an approximate consensus 66.html

59
 Bitcoin version Key contributors Summary Context Source code update Insights on the true Satoshi vision Link to forum Forum post date
post
Satoshi The official version is released after more This row is based on Bitcoin v0.1.0 ALPHA "Bitcoin is an electronic cash system 2009-01-08
Nakamoto than a year and a half of development. This the analysis of the that uses a peer-to-peer network
row is based on the analysis of the original original README file. to prevent double-spending. It's
README file completely decentralized with no
server or central authority." https://satoshi.n
akamotoinstitut
e.org/emails/cry
"The time to generate a block ptography/16/#s
election-9.0-9.21
varies each time, but may take days
or months, depending on the
speed of your computer and the
competition on the network." This
indicates Bitcoin is meant to be run
on a standard user's computer.

Bitcoin v0.1.0 ALPHA Satoshi After more than a year and a half of Doing a UI analysis of Bitcoin v0.1.0 ALPHA Mining is straightforward. All one 2009-01-08
Nakamoto development, the official version is released. the first version. must do to mine is clicking generate
This row is based on the analysis of the original tokens.
UI.
A user can see all previous
transactions they made with its debits
and credits along with a description.

A user can create multiple public H18

the comments suggest, "You may
want to give a different one (address)
to each sender so you can keep track https://satoshi.nak
of who is paying you." amotoinstitute.org
/emails/cryptogr
aphy/16/#selecti
To send coins you can either enter an on-9.0-9.21
IP address if the receiver is online or a
Bitcoin address if the recipient is
offline. There is an optional text
message box to transmit comments.
There is a custom select menu that
has only ONE transfer option
("standard"). The use of this drop-
down box could suggest there would
be more options for transferring
bitcoin.

The SENDER of bitcoin is able

to determine the transaction
fee. IT IS FULLY OPTIONAL.

60
 Bitcoin version Key contributors Summary Context Source code update Insights on the true Satoshi vision Link to forum Forum post date
post
Satoshi Nakamoto; Satoshi released the first public version in his Analyzing the first post Bitcoin v0.1.0 ALPHA "Announcing the first release of 2009-01-08
post. He states the basic functionality and the of the first version of Bitcoin, a new electronic cash system
use of the application. He also warns the Bitcoin. that uses a peer-to-peer network to
software is still experimental. prevent double-spending.
It's completely decentralized
with no server or central
authority."

"Generated coins must wait 120

blocks to mature before they can be https://satoshi.nak
spent." amotoinstitute.org
/emails/cryptogr
aphy/16/#selecti
"Total circulation will be on-9.0-9.21
21,000,000 coins. It'll be
distributed to network nodes
when they make blocks, with the
amount cut in half every 4
years."

"When that runs out, the system

can support transaction fees if
needed. It's based on open market
competition, and there will
probably always be nodes willing
to process transactions for free."
Satoshi Nakamoto; Dustin brings up the biggest challenge for Satoshi is replying to Satoshi continues to refer to small- 2009-01-16
Dustin D. Trammell; Bitcoin: "to get people to actually value [it]". the reply of Dustin scale applications for Bitcoin. He has https://www.metzd
owd.com/piperm
Satoshi responds that Bitcoin can be used from Satoshi's original the idea that someone can effortlessly ail/cryptography/2
initially for micropayments on sites and games. post. pay a few cents. 009-
January/015014.ht
ml
It’s already available for pay-to-send email.

Bitcoin v0.1.2 Satoshi Nakamoto; Update on Bitcoin version. Updating bugs. Bitcoin v0.1.2: N/A 2009-01-11

Bugs fixed:
https://www.Bitcoin
• Fixed various problems that .com/satoshi-
were making it hard for new archive/emails/Bit
nodes to see other nodes to coin-list/2/
connect to.
• - If you're behind a firewall, it
could only receive one
connection, and the second
connection would constantly
disconnect and reconnect.

Bitcoin v0.1.3 Satoshi Nakamoto; Update on Bitcoin version. Updating bugs. Bitcoin v0.1.3 2009-01-12

Fixed a problem where your node's https://satoshi.nak

amotoinstitute.org
communications could go dead /emails/Bitcoin-
after a while. The network is running list/22/#selectio
n-9.15-9.29
much more smoothly now with this
version.

61
Bitcoin version Key contributors Summary Context Source code update Insights on the true Satoshi vision Link to forum Forum post date
post
Satoshi Nakamoto; First major update. Updating bugs Bitcoin v0.1.5 There is now a minimum transaction 2009-02-04
Dustin D. Trammell; Adding features. fee for transactions under one cent.
Nicholas Bohm; Changes: (This does get removed in future
updates. It was removed as it caused
• Disk full warning
• Fixed a bug that could occur confusion but limited the risk of DoS
if DNS lookup failed attacks.) Removed the transaction type
• Prevent entering your own selection that only had one choice. All
address in the address book, these updates improve are scaling the
which confusingly changed
the label for your own software as needed. https://sourceforg
address e.net/p/Bitcoin/
• Moved change address button to mailman/Bitcoin
menu under options -
• Tweaks to make it get connected list/thread/CHILKA
T-MID-
faster 0e05a16e-
• Close sockets on exit 6ede-06d8-
• Created minimum fee for 6d65-
transactions less than 1 cent e873c53b3a42%4
• Hid the transaction-type 0server123/#msg2
Bitcoin v0.1.5 selection box that only had 1500063
one choice
• Cleaned up ParseMoney a
little
• Slightly cleaner reformatting
of text message
• Changed the font in transaction
details dialog
• Added some explanation text
to transaction details for
generated coins
• - Reworded the description
for transactions received with
Bitcoin address

Satoshi Nakamoto; Satoshi says next release will take advantage Satoshi replying to a No change. Satoshi wants to enable multiple 2009-02-22
https://sourceforg
of multiple processors to generate blocks. question asking what is processors to generate blocks. e.net/p/Bitcoin/
Will also add interfaces to make it easier to next for Bitcoin. Satoshi wants to make mining more mailman/message
/21646307/
integrate into websites from any server-side efficient / faster.
language.

62
Annex 4: Risk and control framework based on the whitepaper
The diagram below illustrates a risk and control framework which was used to analyze the various key layers of the Bitcoin protocol. The
framework is similar to how one would assess different elements of a network protocol using layer of abstraction similar to the Open System
Interconnection (OSI)83 Model which was also used to compare and contrast similarities and differences between internet protocol (TCP/IP)
and the original Bitcoin protocol.

Step 1 Step 2 Step 3 Step 4 Step 5 Step 6

LayerName Commentary
Broadcast Block of Transactions Proof of Work (PoW) Broadcast PoW Accept New Block New Block in Chain
Phase Description New transactions are broadcast to Each node collects new Each node works on finding a When a node finds a PoW, it Nodes accept the block only if Nodes express their
all nodes. transactions into a block. difficult PoW for its block. broadcasts the block to all all transactions in it are valid acceptance of the block by
nodes. and not already spent. working on creating the
next block in the chain,
using previous hash.

Incentives Businesses that receive frequent payments First transaction in a block is a special Never the need to extract a complete ► Any needed rules and incentives can
will probably still want to run their own transaction that starts a new coin owned by standalone copy of a transaction's history. be enforced with consensus
nodes for more independent security and the creator of the block and is an incentive mechanism.
quicker verification. for nodes to support the network. ► A predetermined number of coins
have entered circulation, the
incentive can transition entirely to
transaction fees.

Risks and Problems  Two nodes broadcast different  Node does not receive a block.  Greedy attacker is able to assemble  Traditional banking model ► Framework of coins made from digital
versions of the next block  Linking is still unavoidable with multi- more CPU power than all the honest achieves a level of privacy by signatures, which provides strong
simultaneously, some nodes may input transactions, which necessarily nodes, he would have to choose limiting access to information to control of ownership, but is
receive one or the other first. reveal that their inputs were owned between using it to defraud people the parties involved and the incomplete without a way to prevent
by the same owner. The risk is that if by stealing back his payments, or trusted third party and the double-spending.
the owner of a key is revealed, linking using it to generate new coins. necessity to announce all ► As long as honest nodes control the
could reveal other transactions that transactions publicly precludes network, but is more vulnerable if the
belonged to the same owner. this method. network is overpowered by an
attacker.

Controls ✓ Nodes always consider the longest ✓ Block broadcasts are also tolerant of ✓ Tie will be broken when the next ✓ Run their own nodes for more ✓ Transactions are hashed in a ✓ The network is robust in its ► Proposed a peer-to-peer network
chain to be the correct one. dropped messages. PoW is found and one branch independent security and quicker Merkle Tree , with only the unstructured simplicity. using proof-of-work to record a
✓ Nodes work on the first one they ✓ If a node does not receive a block, it becomes longer. verification. root included in the block's ✓ Nodes work all at once public history of transactions that
received, but save the other branch will request it when it receives the ✓ System is deigned to be more ✓ privacy can still be maintained by hash. with little coordination. quickly becomes computationally
in case it becomes longer. next block and realizes it missed one. profitable to play by the rules, such breaking the flow of information ✓ Old blocks can then be ✓ They do not need to be impractical for an attacker to change
✓ New transaction broadcasts do not ✓ Distribute coins into circulation by rules that favour him with more new in another place: by keeping compacted by stubbing off identified, since messages if honest nodes control a majority of
necessarily need to reach all nodes ( adding first transaction and starting coins than everyone else combined, public keys anonymous. branches of the tree. are not routed to any CPU power.
As long as they reach many nodes, coin. than to undermine the system and ✓ A new key pair should be used ✓ The interior hashes do not particular place and only ► Output value of a transaction is less
they will get into a block before long). ✓ Allow value to be split and combined, the validity of his own wealth. for each transaction to keep need to be stored. need to be delivered on a than its input value, the difference is
✓ Strategy to protect against this would transactions contain multiple inputs ✓ Only needs to keep a copy of the them from being linked to a best effort basis. a transaction fee that is added to the
be to accept alerts from network and outputs. block headers of the longest proof- common owner. incentive value of the block
nodes when they detect an invalid ✓ Normally there will be either a single of-work chain, which he can get by containing the transaction.
block, prompting the user's software input from a larger previous querying network nodes until he's ► A predetermined number of coins
to download the full block and transaction or multiple inputs convinced he has the longest chain, have entered circulation, the
alerted transactions to confirm the combining smaller amounts and at and obtain the Merkle branch linking incentive can transition entirely to
inconsistency. most two outputs: one for the the transaction to the block it's transaction fees and be completely
payment, and one returning the timestamped in. inflation free.
change back to the sender.

Key Products  New transactions enter here and are  Blocks.  PoW. PoW broadcast. New Blocks.  New Chain (Longest
broadcast. Chain).
 Initial broadcasts.

83
The Open Systems Interconnection (OSI) model is a conceptual framework that describes the functions of a networking or telecommunication system.
The model uses layers to help give a visual description of what is going on with a particular networking system. This can help narrow down problems and help design system to leverage
capabilities and functionalities of the protocol.
63
Annex 5: Highlights of major Bitcoin and BSV protocol changes
The following describes a set of important changes throughout the evolution of the Bitcoin protocol which, in
our opinion, moved the protocol away from Satoshi’s original vision. BSV, in its evolution, made changes to align
their protocol closer to Satoshi’s original vision for Bitcoin. The set of changes described is not exhaustive, but
are, in our opinion, some of the more important changes.

As Bitcoin evolved from the first release, there were numerous hard and soft forks to the protocol, described by
Bitcoin Improvement Proposals84 (“BIPs”) which altered its underlying code and functionality. Many of these
would be considered minor improvements or bug fixes and remaining consistent with Satoshi’s vision, but there
are several notable changes which altered underlying functionality to such a level that we consider these to be
major deviations from Satoshi’s original vision for Bitcoin.

BIP 65 – OP_CHECKLOCKTIMEVERIFY (“CLTV”)

BIP 65’s description on Github is as follows:

“This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY or abbreviated to CLTV)

for the Bitcoin scripting system that allows a transaction output to be made unspendable
until some point in the future”.85

With CLTV, when the transaction is created, the options (including when it will occur) are specified in the
transaction and recorded on-chain. CLTV puts the sender in control of how the recipient receives the
transaction. The recipient is not able to decide. Because the transaction is recorded on-chain, it is publicly
announced in advance.

Within the original Bitcoin, Satoshi included a field nLockTime in the transaction to allow for open transactions
that could be replaced with newer transactions up to the deadline specified. With nLockTime, any number of
signed transactions could be prepared and selected by the recipient for release at the later time, with the
highest version at the deadline being mined and recorded on-chain.

The nLockTime OpCode allows for flexibility and options for the recipients which would be managed via smart
contracts in script. Script could also provide functionality so double spends would be prevented. This
functionality was not enabled at the time of the original release, but supported for future use cases that would
be made possible through smart contracts, such as escrow-type transactions.86

84 https://github.com/bitcoin/bips/blob/master/README.mediawiki
85 https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
86 https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119

64
The key differences between nLockTime and CLTV are :

1. Control/Flexibility – With nLockTime, the recipient is in control of which option is released at a future
time, whereas with CLTV the options are set and recorded on-chain with the transaction.
2. Visibility – nLockTime transactions are kept off-chain until they are released at the time specified, which
keeps them private. CLTV transactions are visible as they are recorded on-chain when they are created,
which limits flexibility.

Another major issue with CLTV is that it is not considered backward compatible with previous releases. The
functionality of CLTV is in contrast to Satoshi’s vision as it limits the users’ ability to create different types of
transactions.

BIP 16 – Pay to Script Hash - P2PH

BIP 16’s description on the bitcoin wiki is provided as follows:

“This BIP describes a new "standard" transaction type for the Bitcoin scripting system,
and defines additional validation rules that apply only to the new transactions.

The purpose of pay-to-script-hash is to move the responsibility for supplying the

conditions to redeem a transaction from the sender of the funds to the redeemer.

The benefit is allowing a sender to fund any arbitrary transaction, no matter how
complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR
code or easily copied and pasted.”87

The P2SH transactions effectively enable the hiding of output scripts by allowing transactions to be sent to a
script hash which are then only spendable when the recipient provides the script that matches the script hash.
This moves responsibility for satisfying the conditions from the sender to the recipient and, because the scripts
are supplied by the recipient, security is essentially unknown to the sender.

There is a very large overall transparency issue created by P2SH in that if the details of the script are not known,
especially the payee information, they cannot be third-party audited unless the redeem script is made available.

This violates Satoshi’s original vision in two ways:

1. With P2SH, there is information hiding of the recipient (payee) as well as conditions in the recipient’s
scripts, which goes contrary to the principle of a ‘public history of transactions’, which includes
transaction details.
2. P2SH can allow for robust privacy practices to be bypassed via the recipient scripts, which are normally
ensured by a true, publicly visible peer to peer transaction workflow as envisioned by Satoshi.

87 https://en.bitcoin.it/wiki/BIP_0016

65
Block size – Several BIPs that were not accepted

Early Bitcoin developers recognized the issues involved in having a limited block size, which included (amongst
others):

• A limited number of transactions per block (thereby limiting overall throughput of BTC transactions to
approximately 7tps).
• Limitations on how much data could be included within each transaction and block.
• Increased fee per transaction due to the limited number of transactions per block.

BIP 101 proposed to replace the fixed 1MB maximum block size with a maximum size that expands over the years
at a predictable rate. According to the BIP 101 proposal, the maximum block size would increase to 8MB in
January 2016 and double in size every 730 days until January 2036. Though BIP 101 provided a solution to the
block size issue, it failed to pull enough support from other Bitcoin developers. Large mining pools were greatly
interested in the proposal, but that wasn't enough to convince Bitcoin core developers to support the
movement and it was withdrawn.

Subsequent BIPs (including 102,103,104,105, 106, 107, and 109) attempted to increase block size through various
mechanisms but were rejected. Bitcoin’s block size remains at 1MB and many of the early limitations identified
still exist.

BSV’s re-alignment with Satoshi’s original vision: Genesis protocol

In February 2020, BSV released the Genesis protocol that included several significant improvements to restore
BSV to Bitcoin’s original functionality, including removing block size limitations, removing P2SH, and restoring
functionality of nLockTime.

Block size
Satoshi established Bitcoin with the intent to have block sizes much larger than 1MB. With the Genesis upgrade
to BSV, this limit will still exist as a configuration option for miners however the default will be changed to no
limit at all. After Genesis it was the miner’s responsibility to manage this limit if they choose to impose it at all.

Remove P2SH support

The Pay-to-script-hash (or P2SH) is a mechanism introduced to Bitcoin to enable hiding of output scripts at the
time they are created. This change removes the ability to run transactions using P2SH. Any existing P2SH coins
will be unaffected, so there is no need to sweep old wallets. This change simply prevents any new P2SH outputs
from being made, re-aligning the protocol to Satoshi’s original vision.

Restore nLocktime functionality

The nLocktime data field is a key part of the mechanism of payment channels that Satoshi describes as a
fundamental mechanism for allowing high speed micropayments on Bitcoin. nLocktime was repurposed by BTC
developers by the new op code CLTV (see discussion above). Along with removing this op code, the original
usage of nLockTime was restored in the Genesis protocol upgrade, which more closely aligned BSV with
Satoshi’s original vision.

66
67