Peer-to-Peer Transactions

BSV enables direct transactions between parties without the need for a trusted third party, reducing transaction costs and increasing efficiency​​​​.

Lower Transaction Fees

BSV's efficient design supports micropayments and low-value transactions with minimal fees, making it ideal for small casual transactions and enabling new business models.

Efficiency in Payment Systems

BSV transactions are confirmed within seconds, making it suitable for time-sensitive transactions without the delays common in traditional banking systems​​.

Flexibility in Use Cases

BSV supports a variety of applications beyond simple payments, including smart contracts, tokens, and complex data operations - all on one blockchain layer - enhancing its utility while maintaining its native efficiency.

Tokenization

BSV Blockchain is a massively scalable utxo based system. What this means is that each transaction output can be dealt with independently by different systems, without worrying about any global state. This means transaction throughput is theoretically unbounded.

There have been many token protocols defined on top of BSV over the years. The most basic way to create a token system on BSV is to simply use an Overlay Service to track specific utxos which have been "minted" as tokens via some tokenization method.

Single Use

If we don't care to track tokens beyond their first spend we could build some simple logic into an overlay which defines a the token as "any utxo which has this specific txid". That way any transaction will be accepted by the overlay so long as it is spending one of a specific set of outputs from a single transaction. You could imagine the use case is a redeemable voucher for $5 off from a local store as part of some promotion.

// minting transaction pseudocode
{ 
    version: 1, 
    locktime: 0,
    inputs: [...fundingUtxos], 
    outputs: [
        {
            script: 'OP_DUP OP_HASH160 {pkh} OP_EQUALVERIFY OP_CHECKSIG',
            satoshis: 1
        },
        ... // repeated x 1000
    ]
}

Say it yields the txid 76730e3d92afcf6a28f8a43bb2c6783685b18170a8da31168364c7b73c9893f3 then we can set the overlay to accept transactions only if one or more inputs contain that txid.

This limits us to either knowing the desired owners of each token at the time on minting, setting the public key hash accordingly; or using a server side private key which pre-signs the utxos with sighash none & anyone can pay before delivering them to a particular owner. This allows them to pass this information around as they see fit, eventually constructing a transaction which spends the utxo using that existing signature, simply adding an arbitrary output when needed.

You can see from this simple example that the meaning of the token is defined by the issuer, and is only redeemable with them.

Multi Use

Creating tokens which can be transferred multiple times while retaining their meaning involves tracing their outputs from one to another.

This can be handled again by a simple overlay which accepts minting transactions as well as transfer transactions and burn transactions.

How you consider the tokens to exist and transfer can be in a push data denomination, or an ordinals approach.

Push Data approach

The idea here is that you mint tokens by pushing a blob of data to denominate the value the token represents while not really caring how many satoshis are associated. In other words 1 satoshi is sufficient for any denomination.

For example a JSON push data might look like:

{
  "sometoken": 1000
}

This would be pushed to the script as a blob of data which is then dropped off the stack prior to executing a regular locking script function.

Thereafter, these tokens are spendable only within the context of the token's issuing overlay. In other words, each spend needs to be send to that overlay such that the new token outputs can be noted for eventual redemption / burning at the end of the token lifecycle.

Transfer transactions would like something like:

The simple rule being "to accept an inbound transaction it must have equal inputs and outputs of each token type.

From the minting transaction onward the issuer of the tokens keeps a working UTXO set of all their tokens, updating them as new transactions come in. This allows them to enforce rules as they deem appropriate for their particular use case.

Ordinal Approach

This would involve using the satoshis themselves to represent specific denominations and using the order of satoshis in the inputs and outputs to define where the tokens were being transfered, rather than the push data.

A transfer would then look like:

In this case, the 0th output would now contain 5 sometokens, and the 1st output would contain 5 sometokens and 9 memecoins. The push data in the inputs refers to token type and token to satoshi ratio.

Thereafter there would be no need for push data, just satoshi values, the tokens would transfer using the order of satoshis in subsequent transactions, thus offering a higher degree of privacy.

Offline Transactions

Fundamentally the benefit of tokens over account based payment systems is that each transfer is independent of all other transfers. This means you can do offline payments, chain a bunch of payments together, and then broadcast everything when you next connect to arrive at a valid confirmed state. Many people can all do this simultaneously, so there is no upper bound to the number of transactions per second which can be facilitated in this way. Payments can occur entirely P2P and settlement can be asynchronous without any underlying issue.

Bad actors cannot fake their tokens since they come with Merkle paths, so fraud is significantly more difficult. Given the time to settle is 80ms or so once connected, there's no incentive to attempt it - you don't know whether the receiving party is connected or not.

Data Integrity

BSV Blockchain provides a globally distributed timestamp server backed by proof of work. What this means is that every block added to the chain is linked to a previous block such that all history of transactions remains immutable. The security of this model is that the chain of hashes is broadly distributed, ideally to all users of the system. This constitutes a very small amount of data - 80 bytes every 10 minutes - while incorporating proof of inclusion for an unbounded number of transactions.

Implementation

Broadly speaking the idea is to contain a proof that some data existed in a transaction which is submitted for inclusion within the blockchain. When a valid block is found, the transaction is in effect timestamped as having existed at that point in time at that specific block height. We can then use the transaction itself, a Merkle path, and the block header to prove it mathematically. This allows us to provide proof that the data within the transaction has not changed at all since its inclusion.

The key primitive which allows this is something called a Cryptographic Hash Function, specifically in BSV we use sha256. If we want to prove data integrity privately, we can publish a hash of the data rather than the data itself.

What this requires is a server to host the data, and a client which knows how to run the proof. The data can be stored like so:

{
    "data": "Enemy at the gate",
    "tx": "0100beef01fe77eb0c000e02fdd8140017...",
    "out": 0, // output index in which the hash of the data appears within the transaction
}

The exact format in terms of the hash algo used, where the push data is within the output, whether it's signed, can all be decided by the implementer based on their needs.

What you can then do as a consumer of the data to check integrity is make a request to the server holding this information. You retrieve the data, which you then hash and check against the transaction data to verify inclusion. Then you run transaction verification:

import { Transaction, WhatsOnChain } from '@bsv/sdk'

// some id related to the content you want
const id = '5ca05a2be61fccf24465525c4692ce92c2f67c43d5cbdd4cbc233e3ed29f4822'

// request from a data integrity overlay
const response = await (await fetch(`https://data-integrity-service.com/${id}`)).json()

// parse as a transaction using the SDK
const tx = Transaction.fromHexBEEF(response.tx)

const data = response.data
const hash = sha256(response.data)

// check if the data's hash appears in the transaction
const included = tx.outputs[response.out].lockingScript.toHex()
    .includes(hash)

// Make sure the tx is really part of the blockchain.
const valid = tx.verify(new WhatsOnChain())

if (valid && included) {
    console.log(data, 'valid data timestamped in block: ', tx.merklePath.blockHeight)
} else {
    console.error('corrupt data')
}

WhatsOnChain provides headers in the example code above - but in an ideal world you would be checking against your own Block Headers Service. We provide free open source software which will get and maintain an independently validated chain of headers you can reference to validate data independently. This is the one thing which is actually important to distribute broadly.

Install

npm i @bsv/sdk

We're using node.js and npm on a local machine, once you're ready to start, initialize a project with npm init -y and install the BSV Blockchain official SDK.

Build Your First Transaction

To create your first transcation you need to send some BSV into a locking script you control. Let's set up our local node.js environment with a key we can use.

// createKey.js
const { PrivateKey } = require('@bsv/sdk')
const { readFile, writeFile, chmod } = require('fs/promises')
const crypto = require('crypto')
global.self = { crypto }

async function createKey() {
    try {
        const WIF = await readFile('.wif')
        const key = PrivateKey.fromWif(WIF.toString())
        console.error('You already have a key file, delete .wif manually if you know what you\'re doing.')
        console.log({ address: key.toAddress() })
    } catch (error) {
        const key = PrivateKey.fromRandom()
        const WIF = key.toWif()
        await writeFile('.wif', WIF)
        await chmod('.wif', 0o400)
        console.log({ address: key.toAddress() })
    }
}

createKey()

Run the above code by copying it into createKey.js and running node createKey.js

Now you should get something in your console which looks like this:

{ address: '1E7ZM72qRDSa0rqUhZoMCMb5MAFYFEaKQp' }

To continue developing and testing, this address will require some funding. This can be done by sending BSV to this wallet, and due the low cost of transactions only a few satoshis will suffice ($0.01 equivalent is recommended). This way, you also ensure that you're not affected if you would lose access to the keys.

If you don't have any BSV, you can find out how to buy it here, or ask the BSV community on X or Discord to send you some funding.

Once you've sent an initial funding transaction to this address, grab the whole transaction from Whats On Chain by pasting in the txid to the search box.

Once mined, a green button which says "Raw Tx" will be visible, which allows you to download the full transaction bytes as a hex string file. That's going to be our sourceTransaction which will fund the transaction we are going to define with the SDK. Copy the hex string into a file in the working directory called .transactions. The file contents should look something like this:

0100000001270ec3f7d507e2593b02297b57f27e8950a7d1df8247efb8203bb4989ef404f0000000006b483045022100a193f3cf1b65910fcf8535318725947fe3d483b80792a7671ca723276aa1999b022039d478124ce96a8bae0fb8da3ed8eeeb8b300b8810407f6665ce7eee8fdf19cb4121030ca32438b798eda7d8a818f108340a85bf77fefe24850979ac5dd7e15000ee1affffffff0310270000000000001976a914d01b0b702ee90e00944342f97c772a8be83e42a288acbc0b0000000000001976a914bc72926a0f5c078fa666bef3105af7a368a8146a88acb81a0000000000001976a914c4bf2c1f5cbc500c38083ca19b99cefba05e583988ac00000000

You can then construct your first transaction by copying the code below into createTx.js and running node createTx.js.

const { readFile, appendFile } = require('fs/promises')
const { Transaction, PrivateKey, P2PKH } = require('@bsv/sdk')
const crypto = require('crypto')
global.self = { crypto }

async function createTx () {
    const WIF = await readFile('.wif')
    const key = PrivateKey.fromWif(WIF.toString())
    const txsFile = await readFile('.transactions')
    const transactions = txsFile.toString().split('\n').filter(x => !!x)
    const sourceTransaction = Transaction.fromHex(transactions.pop())

    const tx = new Transaction()

    tx.addInput({
        sourceTransaction,
        sourceOutputIndex: 0,
        unlockingScriptTemplate: new P2PKH().unlock(key)
    })

    tx.addOutput({
        change: true,
        lockingScript: new P2PKH().lock(key.toAddress())
    })

    await tx.fee()
    await tx.sign()
    console.log(tx.toHex())

    const response = await tx.broadcast()

    console.log(response)

    // append new transaction
    await appendFile('.transactions', '\n' + tx.toHex())
}

createTx()

You should see a response like this:

01000000016dd14cc825fdd4239bae03cd2f7299a7f31f5a4286eac62c47ded0d5c0cd6738000000006a47304402207ce3bddd233f0b2ad04f25e836e69d699d1ad51bd1fdde3c65dab0f7cc13cd94022015c3fc8409145cb60baa483faead2867ac84149b6005a42c1518eb7a77912ba5412102cc6cf85c531f8a27d0d92662c5326d1ddf2941eb0df5fff1921addd37dfc6303ffffffff0150180000000000001976a91421087d3e223806a8c2bea4a1bdaf629a1a3d7efb88ac00000000
{
    "status": "success",
    "txid": "d9c4369a6beec556bec9c5aa3b09e913e91cf8cf2a8fcfd34a10fa3b33296326",
    "message": "SEEN_ON_NETWORK"
}

Congratulations

You're a BSV Developer.

You can keep running the same script - it will keep appending new transactions to the .transactions file until you run out of funds. BSV is so cheap that this could be a few thousand transactions later.

In the mean time, you can create your own Bitcoin ScriptTemplates by defining your own classes like so:

const { LockingScript, UnlockingScript, OP } = require('@bsv/sdk')

class SumScript {
    lock(sum) {
        const ls = new LockingScript()
        ls.writeOpCode(OP.OP_ADD)
        ls.writeNumber(sum)
        ls.writeOpCode(OP.OP_EQUAL)
        return ls
    }

    unlock(a, b) {
        const sign = async () => {
            const us = new UnlockingScript()
            us.writeNumber(a)
            us.writeNumber(b)
            return us
        }
        return { sign, estimateLength: async () => 6 }
    }
}

To create this output you simply add the class to an output:

tx.addOutput({
    satoshis: 3,
    lockingScript: new SumScript().lock(41)
})

Unlocking it in a future transaction you can simply do:

tx.addInput({
    sourceTransaction,
    sourceOutputIndex: 0,
    unlockingScriptTemplate: new SumScript.unlock(21, 20)
})

To check that the script works you can then run:

await tx.verify('scripts only')

Ask the AI if you want to learn more, or join our discord if you need help from a human. If you want to contribute new ScriptTemplates of your own design there's a repo for that here.

For more guidance from the documentation - jump here.

Guides

The BSV Skills Center is a comprehensive collection of documents covering all aspects of BSV Blockchain system. Technology, philosophy, legal, and economic topics are included, along with practical guides for those who want to build on top of it.

How should I begin?

The BSV blockchain implements the Bitcoin protocol in its original design. It offers various capabilities that enterprises can harness to gain enhanced and novel capabilities that were not possible before the invention of the protocol.

It is critical to understand that the Bitcoin protocol is ‘set in stone’ and cannot be altered by any authority. It draws parallels from the TCP/IP internet layer on which the complete digital economy relies today. This is important as applications require the protocol to be stable as any change will have a cascading effect to change them.

Like any other protocol, bitcoin protocol is nothing but a set of rules, categorised as global consensus rules, local configuration rules and communication related rules.

The following sections describe some of the key elements of the BSV blockchain and summarise capabilities unique only to the BSV Blockchain.

The Bitcoin protocol defines the blockchain’s node network and its functioning. Its basic premises are:

• A node is a network actor that adds new blocks to the blockchain.

• Nodes (also known as miners) are characterised by an ability to:

  • produce blocks

  • distribute blocks to peers (other nodes), and validate received blocks

  • distribute found blocks to network peers (note that this doesn't mean the entire block and its contents are distributed as other nodes already have the transactions in the found block - or at least the vast majority of them)

  • Process (validate) transactions

• The longest chain of blocks is the correct chain and is to be used to build new blocks.

• Nodes enforce the rules in the network; they don’t create or modify these rules. A good analogy is nodes are like Police enforcing the rules of law in a city, but they don’t get to make or modify any laws.

• Newly-distributed coins are added to circulation from block subsidies, which form part of the block reward created in the first transaction of each block (Coinbase transaction). In this process, nodes are bound by a unilateral contract by the issuer to perform the functions of a node. If they fail to do so, they will breach the contract and be legally liable for recourse decided by the Issuer.

• Nodes also have a contractual obligation to include every transaction they see in the block they are proposing to create. Sometimes there will be transactions with no fees; they are required to allow those as well until they reach a point where they have to prioritise between fee-paying transactions and free transactions, where they can choose to ignore the free transactions.

• Nodes also have a contractual obligation to protect the network from any malicious activities from network users (for example, hackers moving stolen funds or double spending attempts) or even dishonest mining nodes who attack the network.

Now that we understand the definition of a node, it is also important to understand the concept of the longest chain, which defines the current state of the blockchain at any point in time.

Longest Chain

The whitepaper defines the longest chain in the protocol:

Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.

This description has often been understood as a system providing democratic rights to all participants in the network. However, this majority decision is not democratic. The nature of proof of work and the system's limitations don’t provide a majority decision for users but rather a majority for commercial nodes (block producers). It is not one vote per IP address or machine but rather one vote per unit of investment that decides the ordering of transactions.

Further error is to assume complete autonomy. The longest chain represents the majority decision, but the error assuming that each node must follow this is to ignore the right for a node to follow what the node operator sees as the longest chain of valid transactions. When a node believes the chain is invalid, the node operator can manually override the system and select the alternative chain. Consequently, the argument that a node must automatically follow the longest chain is invalid. Node operators decide what they believe is the honest chain and risk losing profit in the short term to ensure the honesty of the network, which increases their profit in the long term.

This is to specify that nodes always make a conscious decision of which chain they consider to be honest and to build upon.

Blocks

We have discussed blockchain as a public ledger, which is made up of a chain of data structures called ‘blocks’. The blocks are linked together to form a continual chain of blocks using cryptography, hence the term "blockchain".

Block Structure

Each block is an abstraction which is a container of a group of transactions. A block contains a variable number of transactions and a header, called a block header, which includes the block ID of the previous block, effectively creating a chain.

The block header contains the following fields:

• Version. A 4-byte little endian field indicating the version of the Bitcoin protocol the block is being published under.

• Previous Block Hash. A 32-byte little endian field populated by the double SHA-256 hash (HASH-256) of the previous block header

• Merkle Root. A Merkle root is the hash of all the transactions included in this block.

• Timestamp. A 4 byte field containing the Unix epoch timestamp applied to all transactions in the block. Current network policy only requires this value to be accurate to within 2 hours of the validating nodes’ local timestamp. The timestamp has a 1 second precision.

• Bits/Difficulty. The difficulty is a 4 byte field containing the difficulty target value of the proof-of-work puzzle; determined by the network rules.

• Nonce. ‘Number Used Once’. The nonce is a 4 byte field that is cycled through during the proof-of-work hashing process to find a proof-of-work solution.

Merkle Tree

The block arranges transactions in a specialised structure known as a Merkle Tree. The root of the Merkle Tree is a single value that protects the integrity of every transaction in that block. This value is stored in the block header as Merkle Root, as shown in the diagram below.

The Merkle tree is the original implementation of a hash tree, proposed by Ralph Merkle in 1979, which is typically interpreted as a binary hash tree. Merkle trees are formed from multiple data elements (In this case, actual transaction data) by first putting each element through a hash function (the transaction ID) to generate the leaf nodes (shown as TXID in the diagram) at the bottom of the Merkle tree. To generate the upper layers of the tree back to the root node, these leaf node values are then concatenated together as ordered pairs and hashed to form another fixed-length string on the next layer up of the tree toward the single root value.

Each leaf node consists of a hashed data entry, so 'n' data entries would result in 'n' leaf nodes. Moving one up the layers, we combine leaf node values by hashing the concatenation of the two individual values provided at the previous layer. This process is repeated by going level up every time there are two node values until the complete information is captured as a single value known as the Merkle Root. The diagram demonstrates this process for a 4-leaf Merkle Tree.

If there are an odd number of transactions, suppose there is no tx4, the hash 3-4 will be the hash 3-3 by using tx3 hash twice and the same process applies. Demonstrating that a leaf node is part of a given Merkle tree requires computing the Merkle Root value by using the leaf node (TxID) and a set of values of all the other nodes needed to calculate the Merkle Root. The set is also known as Merkle proof.

The Merkle Root protects the integrity of all of the underlying data, as even a change of a single character will lead to a significantly different value of the Merkle Root. In some ways, it represented the checksum of the underlying data. This is why a block header represents the identifier of a group of transactions and ensures the integrity of all the transaction data it contains.

Hash Function

Hash mentioned in the above diagram represents a cryptographic hashing function, which is a one-way function i.e. it is easy to calculate the hash value from the original data but computationally infeasible to calculate initial data values from the hash.

A cryptographic hash algorithm produces irreversible and unique hashes. The Bitcoin protocol uses the SHA256 hash function extensively. In cryptography and computer science, a Hash or Hashing function can also be considered as a unique digital signature produced by a data block when passed through a mathematical cryptographic function, in this case, SHA256.

Another important component of blockchain is the concept of the Public-Private key-pair, which is a common tool used to enable the possession of exchanged value on the blockchain and is achieved using PKI or Public Key Infrastructure.

Public-Key Cryptography

Bitcoin (BSV) protocol uses public-private key-pairs extensively to assign possession of native tokens. An important point to note is ownership and possession are two different concepts, and ownership is a legally binding term which requires proof of how the acquisition of said ownership happened. What this means is that all tokens at any given time are associated with a unique locking script (often a private-public key pair) but a single entity can contain more than one key-pair. In fact this is the default method to possess the tokens.

The mechanism is such that the tokens are locked to a public key, and only the owner of the corresponding private key can access the tokens. The process is described in the following diagram.

Every time a new transfer of tokens is made, it creates an output where the tokens will be locked to the next owner's public key.

The salient properties of BSV Blockchain that make it a transformative innovation are :

• Immutability - BSV blockchain is an immutable ledger of transactions and data, with each block timestamped. In mathematical terms, blockchain records permanent evidence that an event ‘e’ occurred at time ‘t’. Blockchain relies on two concepts to achieve immutability: a distributed timestamp server, and proof of work. Distributed timestamp server hashes the transactions of the block and associates it in the block header along with a UNIX time value of the formation of the block. This hash is unique to the block, and since it is generated from the contents of the block, changing the contents would invalidate the hash stored in the block header at the time of block creation. Generation of this hash requires miners to invest in cap-ex and spend considerable op-ex in recurring electricity bills. For a miner to prove that the block was mined by it, it needs to exhibit proof of work, which is easily verifiable by other miners in the network. Proof of work is a form of cryptographic challenge or puzzle, which requires extremely high hashpower (compute resources) to solve and, at the same time, very easy to verify once a solution is available. As the name suggests, it proves to the network that the miners have spent a significant amount of computational efforts

• Distributed - For consumers and businesses a node network is a distributed network. The protocol mandates for each node to agree and have an identical copy of the blockchain. Each node executes an identical set of immutable rules i.e. programmed as part of node software. This provides resiliency to the network, as there can never be a single point of failure for end users. It also adds an element of trustlessness to the network, as end users do not have to trust a single node for validating the integrity of transactions. Lastly, it makes the system economical for end users, specifically for businesses. They would be charged a fee for each transaction, which in turn could be negotiated as miners compete amongst each other to get more and more transactions. The nodes within themselves are hyper-connected, and as the network matures, the network topology between the nodes will emerge as a small-world or mandala network.

• Privacy and Accountability - Bitcoin protocol handles privacy by separating the identities of the two parties transacting on the transactions. For transferring funds, the sender needs to sign the ownership of the coins using a private key (without revealing it), and in the same transaction, the receiver's public key is associated with the transferred coins. This provides pseudonymity to the users while the ledger remains transparent and auditable. Additionally, the immutability of the ledger implies accountability. As the transactions in the block cannot be erased or changed, it stores the digital footprints of individuals and businesses forever, bringing in accountability. Any illegal or criminal activities done using bitcoin can be easily traced via the immutable evidence trail and hence subject to action by the law enforcement system.

• Security - Like many existing systems, security is both the responsibility of users and the protocol. For individuals and businesses, there are recommended best practices to be followed which are outside the scope of this topic. From the protocol perspective, the protocol implements the philosophy of economic security. There are multiple facets to it:

  1. The keys that provide access to ledger databases are not stored in the blockchain itself and are distributed across diverse systems, making it uneconomic for any adversary to attack such system. This is unlike existing systems, in which sensitive information such as credit card details are stored in a single database, which makes it susceptible to hacking.

  2. The integrity of the transaction, specifically double spend, is the responsibility of the miners and protocol mandates that not only the miner who mines the block validates it but also the majority of nodes perform the same validation before the block is accepted as valid.

  3. Finally, the aspect of economics is incentives tied to the Proof of Work. It takes a huge investment, in terms of hash power, from nodes to mine blocks and keep running their business profitably. The protocol mandates nodes abide by the same set of immutable rules to form a consensus. If a node decides to waste hash power in attempting to get an invalid transaction accepted in the block, they limit their revenue-generating ability, as other nodes will not accept the block. If any node decides to overwrite the transaction in the blockchain, the protocol requires it to build a new proof of work chain and outpace the constantly lengthening chain-tip of their blocks to be considered as valid. This makes it computationally impractical to change or erase transactions captured in a block

• Federated Network Consensus - The Byzantine Generals Problem deals with establishing consensus among nodes in distributed computing, such that the reliability of the system remains intact. The consensus mechanism used in the protocol is “one CPU, one vote”, which implies the percentage of voting share for the miner in the network, depends upon the number of CPUs that the miner has and utilises continuously. In terms of the Byzantine Generals problem, where each node or miner is a General, the vote share is directly proportional to the strength of the army, i.e. the number of CPUs a miner has invested in and utilises to solve the puzzle to compete with other miners. This investment, referred to as "having skin in the game" in layman terms, ensures the honesty of miners towards the network and they act to keep their incentive intact, effectively providing an economic solution for the Byzantine Generals problem.

• Scalability - With respect to the scalability of blockchain, enterprise product design needs to be cognizant of two facets - block size and individual transaction size:

  1. Block size - In 2020, BSV Blockchain's main network processed a 340 MB block containing over a million transactions which was quickly followed by 369MB containing 1.3M transactions. By 2023, the largest block that the network has processed went up to 4 GB, and additional days showed more than 50 million transactions processed in a single day with the network. The main network comfortably handles 2.800 transactions per second, and the scaling test network has handled a peak load of 6.000 transactions per second. Currently, work is underway to re-architect the node software from monolith to a modular/microservice design for further scaling. The aim is to achieve a much higher throughput starting with the immediate goal of 1 million transactiosn per second, making it the most scalable blockchain today. One of the pivotal consequences of allowing big blocks is that it reduces the transaction fees for the miners and in turn. This makes BSV the only blockchain that supports micropayments.

  2. Individual Transaction size - The protocol also offers scalability on the transaction level where it uses a native language called Script for supporting various contract types between entities exchanging value in the transaction. These scripts present in transactions contain not just payment information (digital signatures, value etc.) but can also contain data. There is no limit imposed in the protocol on the number of inputs or outputs, and each script can have up to a maximum of 4.2 GB of data items. This allows Bitcoin transactions to work as payment and data transactions, using the bitcoin ledger to become a real data ledger.

• Peer-to-peer exchange - There are 2 important features of the protocol which enable peer-to-peer transactions between non-trusted parties. One is Simplified Payment Verification (SPV), and the other is a Payment channel for input in a transaction. Notably, both these features enhance scalability and cost-effectiveness for an enterprise using the bitcoin protocol. SPV allows blockchain users to run a minimalistic infrastructure focused on the transactions they generated, making the cost of their operations to run a blockchain almost negligible. Payment Channels are mechanisms that allow for building a series of interconnected transactions (almost like a sub-ledger) while only a single transaction is recorded on the blockchain. These interconnected transactions at any point can become this one transaction depending on the business use case. As well as the provision of throughput capacity, the blockchain also processes transactions for minimal fees, consistently less than a hundredth of a US cent.

With a stable base protocol and technical plumbing in place, this innovation has the potential to power the emergence of new data business models in a variety of industries such as Healthcare, eSports, supply change management, the Internet of Things, Big data applications, remittance, distributed network intelligence, privatised identity system and many more.

Built on the foundation of scalability, stability, security, and instant transactions, the BSV blockchain promises to be the right choice for enterprises. It revolutionises the existing business models by providing micropayment capabilities. It also safeguards enterprises by providing them with data integrity and fraud detection capabilities. Being a public ledger, it introduces transparency in accounting and bookkeeping. Providing a platform for micropayments (one of its core capabilities) enables an alternative for the data economy to evolve beyond the current advertising-based Internet model. The technology itself is still nascent, and much work is being done to innovate with the unique capabilities that a blockchain provides.

Transactions are events that are recorded and persisted on the public ledger. They are organised into blocks: a group of events that occur over a period of time that are time-stamped together.

Transactions are made up of inputs and outputs. An input will unlock the tokens it intends to spend, transferring ownership of funds from one owner to another. An output will lock tokens to the new owner. Transactions can also be considered electronic contracts that move the ownership of funds from one party to another.

To illustrate this, let’s look at some transactions between Alice, Bob, Carol and Dave. These transactions can be in the same or different blocks and can happen at any time, as shown in the following diagram.

Alice is represented in the ledger by her public-private key-pair, but her identity is not published. When funds are transferred from Alice to Bob, a transaction is created where Alice provides her digital signature stating that she owns the funds (source of funds for Alice), and that she is transferring the ownership of them to Bob by locking access to them with Bob’s public key.

The transaction itself does not have any identifying information associated with Alice or Bob. The diagram then shows that Bob, who has received funds from Alice, now has the private key able to spend the funds. He uses transaction T2 to transfer the funds to Carol. Carol then transfers the funds to Dave in transaction T3.

The first transaction of every block is called a "Coinbase transaction". This transaction does not have an input and has a single output which acts to bring coins into circulation as a reward for the node which won the right to add the relevant block to the blockchain in a process known as Proof of Work. This reward consists of two components: a block subsidy and transaction fees. See Network Policies and Transaction Lifecycle for further details.

Transaction outputs that have not been used as inputs (yet), i.e., spent, are called UTXOs (unspent transaction outputs). Just as in a bank where the total account balance of all accounts represents the total funds present in the bank, in a blockchain these UTXOs collectively represent all the tokens that can be used in subsequent transactions in the system at a given point in time.

The following diagram illustrates this comparison while also describing UTXO creation and end of existence. Blockchains maintain a UTXO database, which stores the current state of all UTXOs that exist at any point in time.

There is a significant difference in terms of processing when it comes to Accounts vs UTXO. A single owner can have multiple UTXOs for a single key or even have one keypair per UTXO. Unlike an account, the Identity of the owner is not attached to the UTXO and there is no need to maintain account balances (which is quite normal in account-based systems).

The UTXO model allows a blockchain to parallelise transaction processing, which is a critical factor in scaling a blockchain.

In the same way, when you spend a UTXO with 100 satoshis, this will transfer the ownership of 50 satoshis to the new owner, you may perhaps incur 10 satoshis in fees, and a new UTXO of 40 satoshis will be created, which might even be assigned to the same public key that it was spent from originally, but it becomes a new UTXO as the attributes of UTXO change (location of UTXO in a new transaction).

Transaction Inputs and Outputs

In traditional payment systems, a transaction will have a single input and single output due to the usage of account-based ledgers (Credit, Debit). Bitcoin's UTXO-based ledger allows a transaction to have many inputs and outputs.

Each output contains a predicate (evaluates to true or false) locking script that that must receive the correct missing information in order to evaluate to true when being included as an input in a new transaction. This property makes every transaction an electronic contract when used in conjunction with the public ledger. Locking scripts use a native programming language called Script (colloquially Bitcoin Script), allowing a large variety of electronic contracts to be supported natively.

These transactions effectively form a chain where the coins start their journey from the time they come into circulation (the first transaction in any block) to where they currently are assigned in terms of ownership (public keys of owners of these coins). This structure is what makes a coin effectively a chain of digital signatures.

Proof of Work (also: Proof-of-Work or PoW) is a network consensus process where many non-trusting nodes compete to add the "next" block in the blockchain. Each node creates a block based on the transactions they have received and propose it to the network for consensus. If majority of nodes agree to the proposal, they agree for that block to be the valid block addition to the blockchain. Every node of the network at any point in time will have a block proposed (called a candidate block) but they inform the network about details of this block only when they have found a solution to the mining puzzle. They all compete with each other in this race to find the solution for the mining puzzle. But in network consensus process, they cooperate with each other to ensure the validity of the proposed block.

If you observe, It is in the self interest of the node to perform this validation honestly because they will be deploying expensive resources to build their proposal of block on this decision.

This is shown in the diagram below.

The diagram presents the blockchain network analogous to how a client-server architecture is setup. The Clients are network users who produce transactions, and the Server represents the network of nodes that participate in the Proof-Of-Work process to create new blocks and maintain the blockchain's operations. The 'Clients' will submit transactions to the 'Server'. The Server, being the network of nodes, will have all of the nodes collaborating (by sharing every transaction they receive with every other node in the network) and competing (by creating a proposal of a block of transactions which can become the next block in the blockchain). The competition is a puzzle to be solved using heavy machines and when a solution is found, the nodes cooperate again to validate the proposed block. When they all agree on a single answer, the new block is added to the blockchain.

The node network consists of nodes that process transactions from the users of the network. These nodes, running specialised software which implements the Bitcoin protocol, operate according to a strict ruleset and act as the enforcers of the ruleset in the network. A good analogy is that nodes are like police enforcement who implement the rules which are created by the judiciary and parliament for a country.

A Blockchain based on the Proof-of-Work consensus specified in the Bitcoin protocol replaces the trusted intermediaries in a value exchange network with non-trusted nodes that are agnostic to the trading activities the transactions represent.

It allows for open and permissionless network usage by anyone willing to pay the transaction fees. But it makes the system vulnerable to many possible attack vectors, including publishing malicious content on the public ledger, theft of keys and other frauds.

The Bitcoin protocol addressed this using a messaging system termed the Alert System. This enabled nodes to exchange messages regarding the maintenance of the network's health and protection from any malicious behaviour. The recently established Digital Asset Recovery process implements one of the Alert System's use case with a standardised system of governance for the blockchain network. It also acts as an interface to the Judiciary and legal system in the network, providing a recourse mechanism to innocent victims of illegal activities.

BSV is the only blockchain that allows legal recourse for lost asset (token) recovery to legally rightful owners by design. The same system can also freeze assets based on court injunctions and legal notices. This process enables the blockchain system to work under precisely the same legal system that any financial system currently is subjected to in law. It also discourages any illegal activity that the open and public ledger can face by malicious actors.

Every node in the network will maintain a Blacklist containing asset freeze and recovery orders issued by courts. These orders could involve UTXO addresses requested by the court to be frozen due to their involvement with an illegal act in law. There could also be an Asset recovery order which could involve the reassignment of funds from a UTXO to a recovery UTXO, possibly for recovery of theft of funds from the rightful Owner via court case judgement. This system describes the following attributes of a blockchain system.

1. The existing legal system dictates ownership of funds, and blockchain tokens follow the same rule.

2. Any illegal usage of a blockchain is disincentivised as funds and addresses are easy to freeze, and recoveries can be made quite swiftly.

3. Nodes are obligated to follow their local jurisdiction's court orders, and this way, they are also regulated by the same jurisdiction.

The innovation the Bitcoin protocol brought about was an economic system linked to a traceable pseudonymous series of transactions. Proof of Work-based Cryptocurrencies, the concept of a timestamping server, and Distributed Cryptocurrencies have existed for a few decades. Even the concept of a blockchain (hashing a block of information into the next block), was first published 25 years ago.

The Proof-of-Work process needs to be more understood regarding its nature as an "economic medium": a game theoretic signalling system. In game theory, you can look at something like a peacock. A peacock signals its health and fitness through the size of its tail. If the tail is too long, it won't be strong enough to get away from predators, and hence it will be killed and unable to breed. Conversely, the peacock with a longer tail tat survives, demonstrates to the females that it is strong because it can survive with a tail of that size. A peacock's tail has value as a signal because it has no real value.

An investment in the PoW is an economic form of signalling. What matters is that the signal is expensive. Proof of Work (as a peacock's tail) is a means of proving the willingness of a party to invest a large sum of money in infrastructure to secure the network by validating transactions and ordering those transactions into blocks, that other miners will validate profitably. As the block reward subsidy vanishes, the transaction fees become increasingly important. In time, a miner who primarily concentrates on something other than ordering transactions will gain little to no remuneration. PoW hashing by itself has no other value, just like the peacock's tail.

Mining nodes signal (with PoW) that they are willing to lose money and take a risk in keeping the network secure. They are willing to pay large sums of money to invest in the network, demonstrating a long-term commitment. Most importantly, it involves a large fixed asset capital base at risk if these miners seek to act outside the law. The biggest control in PoW mining is the existing legal system. A miner who decides to act outside of the law with enough hash power to overpower the honest nodes in the network is simple to detect. Most importantly, they provide signed evidence admissible in court and allow criminal prosecutions. Additionally, other miners would legally be able to take action. Action would include anti-competitive behaviour and other protections that are associated with cartel-based action.

Due to this nature, the blockchain system defined by the Bitcoin protocol is not a cryptographic system, but rather an economic system that uses cryptography. Let us understand how this happens further by understanding various concepts involved in the Mining process.

Token and its distribution

A blockchain network is unique in terms of its incentive structure, which involves money built into the network essential for such a public network's security. In the case of BSV Blockchain, the native token is Bitcoin(SV) or simply BSV. It is an abstraction representing the fundamental, indivisible unit of value inside the network known as Satoshi. A single BSV coin is just a denomination representing 10^8 Satoshi.

When the network was launched In January 2009, all native tokens that could be created in this system were issued (specified in the ruleset and codebase). The system has 21 million BSV or 2.1 quadrillions (21,000,000 * 100,000,000) of Satoshi tokens. At the time of creation or minting of these tokens, the value of all 2.1 quadrillion tokens combined was equal to zero. These tokens gain value based on their utility to enable transacting with the blockchain network. The higher the number of transactions, the higher the utility of the blockchain network giving any value to the token. In short, the token's value is determined by the open market of trade and the utility of these transactions in commercial activities.

These tokens are distributed in the network to its participants via a process called Block subsidy. This mechanism acts as a financial incentive for nodes to perform their function in the network to create blocks by processing transactions. This block subsidy follows a deprecating model where it gets reduced by 50% every four years. The distribution started at 50 BSV in 2009 per Block; currently, it is 6.25 BSV per Block and in 2024 the block subsidy will be halved to 3.125 BSV per Block.

In future, the network will have minimal subsidisation, and the majority of the earnings for nodes will depend on transaction fees. This is illustrated in the following diagram.

It means the network needs to have as high a volume of transactions as possible to meet the nodes' expenses in offering their services as transaction processors. Supporting this volume of transactions will require that the network is providing usage for the multitude of use cases that a blockchain offers, like micropayments, Central Bank Digital Currencies (CBDC), data transactions and digital contracts.

The flip side of having a native token in the network and using it for transaction fees is the volatility of the token's price and its potential for upsetting the business revenue forecasts and planning. This is an issue in blockchains, where the token prices are a driving force of network participation and a speculative investment asset. In the case of the BSV blockchain (where the transaction fees are typically set to an extremely low value) it need not be a cause for concern. Currently, the transaction fee is 0.05 Satoshi per byte, totalling up to the fees of 1/1000th of a cent for a 300-byte transaction. Even if the price fluctuates significantly, it is unlikely to cause any noticeable impact on a company's budget and revenue planning.

One last aspect of the token system is its limited supply which is frozen with the Protocol. The entire security of blockchain relates to the exchange of tokens. If 100 people want to create entries and there are only 99 tokens, there is an economic incentive to transfer tokens (in transaction fees). There is no incentive if you don't have transaction fees, a token for payment, or something else. In today's market, it is a game of musical chairs where there are a million chairs and only 100 players. In the future, there will be billions of players and only a million chairs. If transactions are based on the exchange of something other than the tokens, and you don't exchange tokens for making an entry, then you have just changed the game by making an infinite number of chairs.

Network Consensus

A Blockchain uses a network consensus methodology (defined in Bitcoin protocol) to determine who can add new blocks. This methodology is specifically designed to make the (mining) nodes become a known public entity. Being a node requires setting up data centres for storing the distributed ledger (currently running into many terabytes) and participating in a computation-heavy process known as Proof-of-Work, which requires machines possessing strong computational power. All this infrastructure means that if, for example, legal action is brought against them, there is an economic cost to these nodes.

There is another reason for such a system design:

In a proof of work system, what you did yesterday or what you do today does not determine what you will do tomorrow and hence what you will earn or control tomorrow. The requirement for continuous investment changes the nature of the system in proof-of-work.

The Bitcoin protocol intended to replace trusted intermediaries in a value exchange system with non-trusted ones, which required that these non-trusted entities function honestly. It meant that they are never "at rest". The PoW system described above would strip any entity of any advantage they can get (by being early, influential, etc.). They earn only if they perform "the work" and solve the computation. The implementation of this methodology is quite independent of everything the node needs to do for processing transactions, which is described in detail in the node architecture section.

Energy Investment

The PoW system also requires investment in energy to perform such computation. The energy needed for solving the PoW computation is a function of network difficulty based on a mathematical algorithm that adjusts it to keep the difficulty such that it takes about 10 minutes to solve the computation. If there is a significant computational investment in performing PoW, it will increase the difficulty and vice versa.

Technically, the PoW system is independent of the number of transactions that the network processes in every block. Indirectly, however, it is related to the following economic factors:

1. The number of transactions is directly proportional to the amount earned from fees, and gradually, it will become the primary source of incentive for nodes.

2. The computation done by nodes requires energy, and the more the number of transactions in a block, the less energy is consumed per transaction.

3. PoW removes any possibility of monopolies since it removes any unfair advantages to existing participants.

With this background, we will now look at one of the most unique and unusual concepts that the original protocol always intended to be present in the blockchain, but no other blockchain has. The methods and system for a legal jurisdiction to seize assets and issue amendments to records on the blockchain.

We talked previously about the mining process and the participation of nodes in that process. In this section, our focus will be on the technical specifications of the node software, which implements the network policies and participate in the node-to-node communication to ensure that the blockchain is being run according to the blockchain governance ruleset defined by the protocol.

The two main components of a node are the mining pool and the node software that performs the functional work. This is illustrated in the following diagram.

The node software is commonly referred to as Bitcoind or simply BSV Node software, which is based on the original implementation of the Bitcoin protocol implemented as a monolith. There is ongoing work for an improved and scalable microservice implementation of the Bitcoin protocol to support a much larger network throughput of transaction processing. This upgrade will aim to support terabyte-size blocks and more than a million TPS throughput. Such a scaled blockchain network aims to support varied types of transactions and application use cases for global utility and commerce.

BSV Association

The BSV Blockchain network is open for participation and usage by anyone. It uses a native token (satoshi) as a mechanism for paying fees to write to the ledger. The custodian (or steward) of this network is the BSV Association. They are a non-profit organization which acts on behalf of the inventor Satoshi Nakamoto (the Issuer and distributor of the native token, creator of the database, and Bitcoin Protocol). Their work involves maintaining free-to-use, open-source software for the participating entities known as the network nodes.

As stewards of the network, the BSV Association monitors and ensures its protection from malicious activities. They also create and maintain open-source utilities and software tools and contribute to a wide range of community services to advance blockchain technology.

Further information is available using the links below.

Official Website : https://www.bsvblockchain.org

Technical: https://docs.bsvblockchain.org

A number of standard policies are set around network consensus and its ruleset. The consensus rules are codified into the Bitcoin node client software system and represent fixed and unchangeable rules applied across the network. These rules must be strictly adhered to by a node to participate in the network governance process actively.

Genesis Block Rule

The blockchain is anchored to the very first block that was created on Jan 9th 2009. This marked the beginning of blockchain, hence the name, Genesis.

The Genesis Block is special, as it was created with hardcoded values rather than being mined. Part of this block included the first reward of 50 coins. These were designed to be unspendable, which is the reason why this block acts as the anchor to the blockchain.

The 50 coins in the Genesis Coinbase transaction were transferred to a public key which was generated without a private key (ECC or elliptic curve cryptography allows this), making the public key invalid and these coins un-spendable.

- Choose an x-coordinate.
- Compute  y^2 = x^3 + ax + b .
- Solve for y (if the right-hand side is a quadratic residue in the field).

1.	Select Curve Parameters: The secp256k1 curve is selected.
2.	Choose Random x-coordinate: A random x-coordinate is selected.
3.	Compute  y^2 : Calculate the right-hand side of the elliptic curve equation.
4.	Solve for y: Check if the right-hand side is a quadratic residue modulo the prime field. If it is, compute the square root to find y.

The Genesis block rule prevents a malicious party from creating a new chain to perpetrate a malicious redirection of hash power or economic activity. It is an essential aspect of Simplified Payment Verification, allowing users to check they are using the correct chain of blocks with minimal overhead.

The genesis block is identified using its block hash - 
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f.

By ensuring all network users are aware of this block hash, there can be certainty around which chain of blocks is valid. If a user or node connects to a chain of blocks which leads back to the point of origin that is not the genesis block, it can know immediately that it has connected to the wrong network.

Block Size Rule

The size of a block is the size in bytes of the serialised form of the block, including the block header and all of the transactions in it.

The protocol defines the size of a block by the number of transactions a node has seen from the time the last block was mined. No maximum size is defined in the protocol. It depends on the node's software hosting capability. The average block size is expected to increase unboundedly as the network grows over time.

Longest Chain Rule

As described in Mining, the node is ­­­expected to always keep track of the longest honest chain while building on top of that chain. This is the minimal and optimal method for mining nodes to configure their software. If at any time a mining node is intentionally building on an alternative chain than the longest honest one, it is considered malicious and is in violation of the protocol.

Block Subsidy Rule

When creating new blocks, mining nodes are rewarded by block subsidies. These subsidies also perform the function of distributing new coins in the network. The rewards received by the mining node from this activity are considered as financial income and are subject to local income and tax regulation. The services performed by the mining node are also bound under the regulations that any business falls under in their local jurisdiction.

Difficulty Adjustment

The purpose of difficulty adjustment is to maintain the stability of the network operation and to keep control of the rate of block creation to as close to 10 minutes as possible.

This requires that the difficulty level be adjusted based on verifying the frequency of new blocks being discovered. This adjustment is applied in the mining process using the ‘bits’ value in the block header, which impacts the target value calculation (defined by a number of leading zeros in the block hash value). This has been implemented in the node software and is not manually configurable for a specific node.

Network consensus (also known as Nakamoto consensus)

A proof of work quorum system is based on forming a network consensus in such a way that there should be no value at all in the consensus methodology. This is an alternate system to traditional voting by reputation or selection methodologies.

Rather than achieving consensus in the blockchain by voting, they show acceptance of a block by building on top of it. In the protocol, this is defined as 'voting by nodes'. Nodes “vote” for process transactions through the creation of blocks and by building new blocks on previously broadcast blocks of accepted transactions.

The number of nodes that have created blocks is publicly available. At most, 2016 nodes may operate (6 blocks an hour for 14 days) as the difficulty adjustment period of two weeks only allows this number. The difficulty adjustment will reset the count for the new set of 2016 nodes that will mine a block. In general, most of these blocks are created by a small set of nodes, typically numbering between 5-10. So at any point in time, the network votes are fixed to a maximum of 2016 nodes. There could be other nodes present in the network, but if they are not able to create blocks, they are not part of the network consensus and voting mechanism. This makes them just listener clients and not part of the node network.

With the PoW process, the participant nodes in the network change every 2 weeks (along with difficulty). Any nodes that build blocks in the new cycle are considered nodes for that difficulty period. This mechanism allows for open and permissionless-based operations in the network.

By using a brute force-like process, it ensures there is no unfair advantage possible in the process of PoW mining. This key innovation creates trustless and permissionless participation of nodes in the network making them non-trusted intermediaries. When other methods are utilised, this creates an element of trust in the intermediary, making the system vulnerable and a target for malfeasance. The characteristic of untrusted transaction execution in the network is what makes a blockchain innovative.

First Seen rule

When receiving transactions, the first-seen rule is applied to determine which transaction is valid in the case of a double-spend. When a node detects a double-spend, it considers the transaction that it received first as the valid spender of that coin.

The rule has been extended further to add any blocks which are discovered that include the double-spend transaction - those blocks should also be considered invalid, and the node should continue to mine against it unless a second block is discovered on top of that block, indicating a majority of the network has determined that the other transaction was the first seen.

Transaction Consensus Rules

The protocol consist of a set of transaction validation and verification rules and nodes use these rules to interpret transactions they receive from users or other nodes. The following checks are performed:

• Transaction Size: There is a maximum size that nodes by consensus agree to always support. Currently, this is is 10 MB.

• nLockTime and nSequence: These fields are used to create transactions that will become valid in future. The details will be captured in the transaction lifecycle and payment channels (link). Only final transactions are confirmed in the block; until then, they are stored with nodes in the mempool.

• Value Exchanges: The input (spending value) should cover all the outputs and fees.

• Coinbase Transaction: Nodes may not spend the outputs of a Coinbase transaction in a block that is less than 100 blocks higher than the one the Coinbase appears in.

• Transaction Format Rule: Transactions must conform to the data formatting rules of the Bitcoin protocol.

• Bitcoin scripting language and its specification: A set of rules is associated with the scripting language used to create a transaction's inputs and outputs.

When a mining node sets up its system, it will configure the software based on its infrastructure. These configurations come under local policies. Some of these policies are also based on the nodes' preferences regarding the services they want to offer beyond their mandated enforcement of protocol-level rules, which come under standard policies.

These policies are typically associated with the node infrastructure and the node's configuration when setting it up.

There are certain rules related to:

• Block and transaction sizes that the node can support

• Transaction fees

• How the node validates the transaction and blocks received from other participating nodes via the Bitcoin server network

Full List of Consensus Rules and Local Policies

A node has three major components:

• Mining (pool software and ASIC miners) – This component delivers the Proof-of-work for the node. It runs independently and takes the candidate block header (a temporary block that a miner has to mine to gain rewards) as input. The process is described in detail in the next section. The pool software is a sharding mechanism to distribute the hash calculation process to many machines doing the computation, known as proof-of-work.

• Node software – this component performs the transaction validation, block preparation and verification, and the bulk of the core processing to create the candidate block to be added to the blockchain.

• Network – this enables message exchanges between all nodes and mining pools in the network.

The main BSV GitHub is available here, showcasing all public repositories, enabling developers to contribute directly or use as the foundation for their own needs.

This page highlights the main repositories currently available on GitHub:

SDKs

The BSV Blockchain Libraries Project aims to structure and maintain a middleware layer of the BSV Blockchain technology stack. By facilitating the development and maintenance of core libraries, it serves as an essential toolkit for developers looking to build on the BSV Blockchain.

Three core libraries have been developed and made available:

• GO SDK: https://github.com/bitcoin-sv/go-sdk

  • Script templates: https://github.com/bitcoin-sv/go-templates

• TypeScript SDK: https://github.com/bitcoin-sv/ts-sdk

• Python SDK: https://github.com/bitcoin-sv/py-sdk

More information available here

SPV Wallet

The SPV Wallet is a comprehensive non-custodial wallet for BSV, enabling Simplified Payment Verification (as described in the Bitcoin White Paper section 8).

The main repository is available under this link: https://github.com/bitcoin-sv/spv-wallet.

Add-ons

In addition, the following repositories are related to SPV Wallets:

• Administrative console: https://github.com/bitcoin-sv/spv-wallet-admin

• TypeScript client: https://github.com/bitcoin-sv/spv-wallet-js-client

• GO client: https://github.com/bitcoin-sv/spv-wallet-go-client

• Web-Frontend: https://github.com/bitcoin-sv/spv-wallet-web-frontend

• Web-Backend: https://github.com/bitcoin-sv/spv-wallet-web-backend

• AWS cloud formation template generator: https://github.com/bitcoin-sv/spv-wallet-aws

• Helm charts: https://github.com/bitcoin-sv/spv-wallet-helm

• Key generator admin: https://github.com/bitcoin-sv/spv-wallet-admin-keygen

• Fireblocks bridge: https://github.com/bitcoin-sv/fireblocks-paymail-spv-bridge

More in-depth information and guidance about SPV Wallets is available here

Block Headers Service

The Block Headers Service is a Go application used to collect and return information about blockchain headers.

https://github.com/bitcoin-sv/block-headers-client

ARC

ARC is a multi-layer transaction processor for BSV Blockchain that keeps track of the lifecycle of a transaction as it is processed by the network.

The main repository is available here: https://github.com/bitcoin-sv/arc

Full details on ARC are not yet available in this BSV Skills Center, but can be found here:https://bitcoin-sv.github.io/arc/#/

SV Node

SV Node is the main node software used within BSV Blockchain. It is based on the original implementation of the Bitcoin protocol implemented as a monolith. The main repository is available here: https://github.com/bitcoin-sv/bitcoin-sv For more details, see Node Operations and the SV Node installation guide.

There is ongoing work for an improved and scalable microservice implementation of the node software (Teranode) to support a much larger network throughput of transaction processing. For more information, visit bsvblockchain.org/teranode

Alert System

The Alert System must be run together with the SVNode software, to ensure that a node is able to receive alerts.

The main repository is available here: https://github.com/bitcoin-sv/alert-system

To understand the network's policies, it is essential to understand the Mining component in the process.

• Transactions are collected from users and any missing transactions from other nodes.

• These transactions are validated. If valid, the UTXOs corresponding to the inputs are updated and the TXIDs are stored. If invalid, the transaction is rejected.

• The TXIDs are then added to the block candidate.

• A block candidate is the header components of a block plus a candidate merkle root which then gets passed to miners who hash it in the pursuit of finding a hash output that's below a specified target value: called a Proof-of-Work solution.

• Once a Proof-of-Work solution is found, the Merkle root is combined with other defined and undefined fields to create a block header. This contains the following:

  • Version - 4-byte little endian field indicating the version of the Bitcoin protocol under which the block is being published.

  • hashPrevBlock - 32-byte little endian field populated by the double SHA-256 hash (HASH-256) of the previous block header.

  • hashMerkleRoot - 32 byte little endian field represents the Merkle root of the Merkle tree that records all the ordered transactions which are timestamped in the block.

  • Time - 4-byte field containing the Unix epoch timestamp applied to all transactions in the block. Current network policy only requires this value to be accurate to within 2 hours of the validating nodes’ local timestamp. The timestamp has a 1-second precision.

  • Bits - 4-byte field containing the difficulty target value of the proof-of-work puzzle, determined by the network rules.

  • Nonce - ‘Number Used Once’. This is the 4-byte field that is cycled through during the proof-of-work hashing process to find a proof-of-work solution. In addition to the nonce, since ASIC hashing devices can iterate through the complete 4.3 billion value nonce space, nodes also provide them with additional values by iterating the number in a data field within the block’s coinbase transaction (called the "extra nonce") and recalculating the Merkle root; essentially providing additional 4.3 billion value nonce spaces for the ASIC hashers to iterate through.

Version, hashPrevBlock, hashMerkleRoot, time and Bits are decided by the node software, along with a starting value of the nonce. This data is then passed to the mining component, which performs a brute force-like process to keep calculating the value of the double hash of the candidate block header until a solution is found. This process is illustrated in the following diagram with an example target value. The illustrations show an approximation; in reality, the nonce is part of the candidate block or the challenge. Challange or puzzle here refers to the mining solution.

The mining process is also called proof of work (PoW). The solution to the mining process will be passed back to the node software, which will then use the BSN to propagate a set of messages to all of the nodes in the network to inform them about the proposed block. These nodes will then request the node to send them details of the block, which, once received, will be validated in terms of the block data and underlying transaction data to be valid.

Next, the nodes will reply with a message confirming whether or not they accept the block. This process is called Nakamoto Consensus, which results in deciding which block becomes the common ledger history. This is an essential step in the system as it decides what becomes a shared history for the nodes and the ledger.

The consensus is achieved by nodes accepting the proposed block and building the next block with it (including the block ID of the proposed block as the previous block ID in the block header).

The nodes compete to find the solution, and only the first one finding it gets the right to publish the block. for the others the PoW is wasted. once a block is published, a new block competition starts (i.e. nodes create a new block header, etc)

Two or more nodes may find the solution simultaneously, resulting in a temporary fork with two different chain tips (shown in the following diagram as block 3 and 3’).

The fork is resolved when a subsequent block is found, building on one of the proposed blocks (block 4 in the previous diagram). This process results in the earlier node abandoning block 3 and building on block 4.

On a high level, the node software comprises various functional blocks shown in the diagram below. The diagrams do not depict the mining component for illustration of the node software.

The P2P system (also known as BSN or Bitcoin Server’s Network) represents the sub-system which handles the network connections and message exchanges between the various nodes in the network. The term P2P refers to Peer to Peer, which signifies that these nodes participating in running the blockchain network are peers. This means that every node that is a peer is performing the exact same function in the network as another peer. It could provide additional services to the users of the network. Still, from the perspective of the network, it is exactly the same as any other node in the network and holds the same responsibility and functionality.

The other sub-systems, i.e., Transaction validator, Block Assembler, Block Validator and Chain tracker, each comprise one or more services and components to perform the needed functionality. In general, P2P system receives transactions from users or other nodes in the network; they will then be routed to the Transaction Validation process to validate them. Once the transaction is validated, it will become part of the proposed block being built by the Block Assembler of that node. The alternate flow is when another node finds the block to be created, which the Chain tracker will keep track of by listening to messages from all nodes. When it receives a message from a node that they have found a block, it will download the announced block from that node. Once that is done, it will feed the block into the Block validator to validate the block, including validation of all the transactions present in that block.

A detailed view of these functional blocks’ interaction with each other during the node software operation is shown below.

The diagram depicts two main flows, one where it receives new transactions and goes through a validation process to be added to a new proposed block in block assembly. This then is given input to the mining software to perform block hash calculation to find the POW solution. If the solution is found, the proposed block is then propagated to the network via BSN. This flow is highlighted in green. The alternate flow is when another node finds the solution, and this node receives a new proposed block which is then validated by the block validator. The mempool is then flushed out of the transactions that are confirmed by this block, and a new mining candidate block is built with new validated transactions on the top of this chain-tip.

ChainTracker, at all points in time, is responsible for identification and internal updates to many components of the latest tip id of the chain. It also handles communication regarding blocks which fail the validation process.

In general, there are 3 different main flows happening at one point in time in the node software.

1. A node receives transactions and validates them. Once validated, the transaction is also broadcasted to the node network via BSN, so all nodes are aware of the valid transaction.

2. Block Assembler builds a proposed candidate block to be sent to the mining pool software to calculate the mining solution based on the candidate block header.

3. ChainTracker monitors the longest chain tip, and if a new block tip is discovered, it downloads the block and sends it for block validation.

In addition to these 3 main flows, there are sub-flows that happen in parallel.

1. BSN constantly monitors for communication from nodes who are participating in the network and routes incoming and outgoing messages generated at various points in time from the above-mentioned flows. It also includes receiving new transactions broadcasted by participating nodes.

2. Mining pool software keeps querying for updated block templates so that it is mining with a candidate with all possible recent transactions seen by the network. The block assembler keeps adding new transactions to the candidate block periodically and updates the Merkle root due to the addition of these new transactions.

3. UTXO storage keeps updating the status of a given UTXO based on the above-mentioned flows. The final status of UTXO is spent, which is done once it is included in the candidate block by the block assembler or gets verified to be in a block by the block validator.

4. Mempool constantly receives new transactions that get validated successfully. It will periodically update the block candidate, which then is consumed by the block assembler and mining pool.

5. When validating a block proposed by another node, the node shall already know about 97% of the transactions, but the remaining small amount of un-seen transactions are then requested and retrieved by the node.

Please note that we are only touching on node software internals on a high level for what it does. A full codebase can be found at https://github.com/bitcoin-sv/bitcoin-sv where you will find an in-depth analysis of the functionality.

Software Components

A more detailed overview of the node software is shown in the diagram below.

Based on the diagram, we will look at each functional block individually to understand more about each of the boxes shown in the diagram.

Bitcoin Server Network is the name given to the subsystem in the node software, which looks externally and is responsible for all messages exchange and communication for the node software. The word server here refers to the analogy of nodes being the servers for any application that uses blockchain, analogous to Client in a typical Client-Server architecture pattern. The main purpose of the BSN subsystem is to connect and manage peer nodes to:

• Manage the networking and communication for the given node by acting as an Identity of the node and its peers. It also manages connection to every other node that requests a connection.

• Retrieve & distribute network messages such as:

  • New blocks

  • New transactions

  • Chain state

  • Block headers on demand

  • Blocks on demand

A high-level component diagram is show below

Peer Connector

This component is made up of two underlying modules provided by what is known as JCL suite of libraries and operations, and a message router which subscribes to the message events exposed by the JCL-Net of other nodes. The consumed messages are then injected into the system via the Message router. A finite number of peers will connect to a single JCL, and that JCL connects to its own Message Router.

The JCL-Net Module which provides capabilities to connect, listen and react to a Blockchain network. The connection functionality involves aspects such as Handshake protocol, timeout (Ping/Pong) configurations, Node-Discovery algorithm, Blacklist, etc. It also provides event stream and notification capabilities along with supporting network applications to issue request that it can fulfil (for example, requesting a transaction or block).

JCL-Store provides operations to save or retrieve Blocks and transactions that are received or sent as part of ongoing communication with other nodes.

Peer Manager

The Peer Manager component will organise and maintain connections to the other nodes in the network via the JCL. It will also track information about its peers, direct the P2P communications and maintain the peer information and statistics, which will be persisted in the peer store and the peer statistics store.

Peer-Store captures critical identity information (like IP address, port, streams status) and the status of the peer (dead, alive, banned, penalised, unknown, etc.) for all of the connected peers.

Peer-Statistics store will capture statistical information of every message that gets exchanged with the given peer stored in Peer-Store. It also captures in specific performance data for the communication with the peer, which is used by an algorithm to do scoring of the peer. The scoring is used to determine the status of the peer, including if they can be kept active or blocked.

The transaction validation process is composed of many underlying components. These components together orchestrate the execution of steps required for the validation of a transaction. Transaction verification for block validation follows the same criteria as well.

A logical summary of the validation checks done as part of transaction validation are mentioned below:

• The transaction’s syntax and data structure must be correct.

• Neither lists of inputs or outputs are empty.

• The transaction size in bytes is less than Maximum Block Size value.

• Each output value x, as well as the total, must be within the range 0 < x < 21*106.

• None of the inputs have null hash in script.

• nLockTime is less than or equal to 0xFFFFFFFF.

• The transaction size in bytes is greater than or equal to 100.

• The number of signature operations is less than the signature operation limit.

• The unlocking script, and the locking script must comply to validation rules.

• A matching transaction in the pool, or in a block in the main branch, must exist for all the Inputs.

• For each input, if the referenced output exists in any other transaction in the mempool (double spend attempt), the transaction must be rejected.

• For each input, if the referenced output transaction is a Coinbase output, it must have at least 100 block confirmations.

• For each input, the referenced output must exist and cannot already be spent.

• Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values x, i.e. 0 < x < 21*106.

• Reject if the sum of input values is less than sum of output values.

• Reject if transaction fee would be too low to get into an empty block.

• The unlocking scripts for each input must validate against the corresponding output locking scripts.

These conditions are part of the transaction validation process, and every transaction goes through these validation steps. A high-level view of what happens in the transaction validation process is described in the following diagram.

A new transaction that is received by the BSN is passed on to the transaction manager component, which kick-starts the transaction validation process. There are four components that make up the transaction validation process. Let us look at each one of them.

TxManager

Performs basic checks for a new transaction and creates inputs for the transaction validation component.

• TxManager consumes the new transaction message and creates two distinct messages for handling the inputs and outputs present in the transaction

• In doing so, it will first validate the transaction for schema, completeness, and non-duplication

• It then processes the message it created for Inputs and validates each UTXO that is being spent. If the validation is successful, it passes the validated transaction message to transaction validation component.

• It also calls the transaction storage component to store the transaction if its valid.

• In parallel, the UTXOStorage component will consume the message created for the outputs of the transaction, and it will store the outputs as the newly added UTXOs.

TxStorage

Tx storage is used by the TxManager component to store the new raw transaction received after the basic checks are passed, like duplication and sanity checks.

TxValidator

The TxValidator performs the complete transaction validation checks, script validation and produces the final response of the transaction validation status.

• TxManager once it has performed the basic sanity checks, will call TxValidator to perform a full verification of transaction against the consensus rules and local policy rules.

• If the transaction passes all these checks, it will then fetch the UTXO that are being spent by inputs from UTXOStorage and construct the script to be validated by the BSV script engine.

• Each input-previous Transaction Output script combination is then run through the script engine to validate if the inputs are spendable and produce the successful validation result via the engine.

• Once it has iterated through each input for script validation, it will evaluate if all checks are validated successfully

• Any failures at any time will stop the validation with failure message, and the failure message is passed back to BSN.

• If all the validations are successful, it sends the valid transaction to Mempool.

BSVScriptEngine

The BSV ScriptEngine performs the validation for the script presented to it by the transaction validator and returns a success/failure response.

These components together deliver the transaction validation functionality. In doing so, they also interact with the UTXO Storage component and Mempool components.

Except for Coinbase transactions, every other valid transaction spends at least one UTXO and creates zero or more new UTXOs, plus zero or more unspendable outputs. The UTXOs that are being ‘spent’ obviously must come from previously successful transactions, and these may be recorded in the current or a previous block.

An unspent output may be created and spent in a few milli-seconds, or it may remain unspent for decades, depending on when they are used in a transaction. This means that the unspent outputs must be persisted for as long as they remain unspent.

UTXO Storage comprises of set of components which handle storage (short term and long term) of UTXOs. Due to the nature of the storage which would sometime have requirement of some UTXOs being maintained in cache, short term memory or some in long term memory so the storage itself is designed in such a manner that it supports the needed access of these UTXOs based on how active they have been. It also is used by most of the node components to get status of the UTXOs as described in the diagram below.

A UTXO can be in various possible states at any point in time in the database. Each of the processes does its own set of interactions with UTXO Storage.

1. When a new transaction goes through the validation process, this will initiate the creation of new UTXOs (present in this transaction's Output).

2. When the TxValidator is validating a transaction, it will fetch the UTXOs which are being spent in the input of the transaction it is validating. It will iterate through every input present in the transaction and fetch the UTXO, while the UTXO entry in the database itself will be locked so that no other transaction can now spend the UTXO (in a way, this is how the first-seen rule is implemented in the node)

3. Once validated by the script engine and posted to mempool, the locked UTXO status will be changed to Spent.

4. The new UTXOs created by this transaction will then become available for spending by a later received transaction.

5. Error scenarios are possible where the UTXOs are not found or are unspendable due to incorrect script or sometimes even missing. These will be handled accordingly, resulting in an invalid transaction error.

6. UTXOs are always created based on a Tip ID. So, if the Tip-ID changes, the state of UTXO changes as well. This is kept in sync by interacting with the chain tracker.

7. Block Validator and Assembler also use UTXO storage services to ensure the validity of the UTXOs that they are consuming.

ChainTracker as the name suggests tracks the longest chain of blocks in the blockchain network. It is also responsible for responding to the BSN when a message from another node is received regarding the discovery of a new block. It is also responsible for ensuring the node state is responded to so that, at all times, the node is in sync with the external node network.

If at any time the node is out of sync and needs to download blocks from the network, ChainTracker orchestrates that in collaboration with Block Downloading and storage services. Once downloaded, it will pass on the blocks to Block Validator.

ChainTracker stores all the Block Headers that make up the Chain. For each Block Header ChainTracker also stores a piece of “Metadata”, this is a placeholder to store flags or relevant info about the block mentioned below:

• Number of TX’s

• Download timestamp

• Download source

• Validation timestamp

• Number of Validations (in case of a block being validated several times, for example when a block is corrupted, and we need to download and validate it again).

ChainTracker will query other peers in the network to get headers of the blocks in the Chain so it can build the Chain internally from Genesis up to the Tip. It keeps track of the blocks being validated and makes sure that other components in the node are aware of those blocks and are informed when they are Validated or Invalidated.

An overview of Chain Tracker is provided in the following diagram:

It is the central component that interacts with the Tip Manager, which monitors incoming communication from Chain Trackers of other nodes via BSN to receive the TipIds.

ChainTracker also communicates with mempool to sync it with the active tip id, and when it needs to update the valid tip id recognised by the mempool, it sends a message to Mempool for this realignment on the tip id; the process itself is termed pool rebase. It also interacts with the UTXO storage services to ensure the tip recognised by them is in sync with the longest tip recognised by the network. This ensures that the UTXOs and their status are reflected correctly based on the longest chain of work in the blockchain.

Nodes can minimise storage requirements by pruning transaction data that have a minimal or no chance of being required in future. Many times, there will be transaction data which contains outputs that are also spent by subsequent transactions, effectively making these transactions redundant data for a node to store. They can be discarded to optimise storage and processing capacity for the node.

Let us have a look at what this means.

Suppose in the demonstrated block, Bn, there are tx1 to tx4, which contain UTXOs that are spent by transactions in later blocks, and by the time the chain-tip is at block Bn+m, all of the UTXOs are spent. Now as shown in the diagram, the orange data blocks of transaction data is something that the node will never have any use for. The node, as shown, can delete transaction data for Tx1, Tx2, Tx3 and Tx4 and just use their hash (TxID) and still will be able to calculate the Merkle root for this block for any verification purposes in future. In fact, it can go a bit further since the complete set can be deleted, including the hashes to the next level, as shown in the diagram. So, the node can delete the hashes Tx1 to Tx4 on level 1, HTx1-2 and HTx3-4 on level 2 as well, and the hash HTx1-2-3-4 can still provide the needed hash for any future Merkle root calculation needs that could come up for example when validating the presence of transaction Tx5 in the block.

Also, as shown in the diagram for Tx7, a miner can choose just to delete the transaction data so save storage space and keep jus the TxID which is the hash of the data and optimise their system.

This capability can be also useful in case of node for deleting any transaction that contains any illegal content as data in them or any transaction data that is deemed malicious or required by the legal system to be removed from blockchain storage.

Pruning is a very useful capability for nodes to optimise their operations and only store what they really need and nothing else. This, however, will also make nodes sometimes delete transactions that are created specifically to upload data with non-spendable outputs (ex., OP_RETURN data outputs with 0 value in terms of Satoshi). Applications that plan to utilise such outputs for their purposes shall ensure that they have stored backup of their data transactions, including Merkle proofs, so that blockchains can still be used for their transaction verification using SPV methodology. Alternatively, there is always the case of new business models emerging for what is called as archival nodes who achieve blockchain data and provide a paid service for anyone who wants to access that in future.

Mempool references a temporary location where transactions that have been validated are stored for a certain amount of time. Its purpose is to manage and publish unconfirmed transactions, which entails:

1. Keeping the transactions in memory,

2. Providing information about coins spent by transactions in the mempool,

3. Providing information about UTXOs created by transactions in the mempool.

4. Keeping transactions consistent with changes on the blockchain (adding a new block, reorg).

5. Maintenance, deleting stale un-mined transactions, limiting the total size of all transactions in the mempool.

It also provides the following crucial services to the Block Assembler:

1. Feeding the Block Assembler with topology-sorted mineable transactions.

2. Notify block assembler to delete removed transaction and make sure that all its children are also removed.

3. Keep a pool for low fee (if any), non-final and time locked transactions. Filtering transactions by its fee and prioritisation is done by this component as well.

All transactions in the mempool are stored in a single storage. However, depending on the state of a transaction, a terminology is used as if there are different types of mempools.

A transaction is in one of the following mempools:

• The Primary Mempool: Transactions selected for the next block built by this node

• The Secondary Mempool: Transactions not selected for the next block

• The Non-Final Mempool: For unconfirmed transactions.

The following diagram shows the interactions with other components.

The following steps describe the functionality of the Mempool during its usage in various transaction validation, block assembly and validation processes.

• Processes the validated transaction to be provided to the block assembly

• Broadcasting transactions via BSN once validated

• UTXO status provider for validation service (both spend and un-spend)

• Provide validated transactions to block assembler

• Provide transaction data to Block validation when it is processing downloaded block from another node to validate it

Mempool plays a central role in deciding which transactions get mined, and it is constantly updated after a successful block creation by its own or another node in the network. If we consider a Mempool as a set of transactions, the mining process will result in the following updates to the mempool:

Block mined by another node in the network:

New Mempool = Old Mempool - Mined Transactions – Double Spend Transactions - Children of Double Spend Transactions.

Block Mined Locally

New Mempool = Old Mempool - Mined Transaction

A transaction is removed from the mempool when it reaches its expiry date (default is 2 weeks after entering the mempool). After a new block has been created and propagated to other nodes, the transactions in the mempool, which are also in the new block, are no longer needed in the mempool and can be removed. If the block created by this node is also the winning block, then the transactions not being needed any more are all the transactions in the primary mempool, except those added after the block construction is completed.

SPV is a process to verify the presence of transaction in a block. The 'payment' part of the term stems from the fact that blockchain itself is an electronic cash system, and every transaction is a payment. Even when a transaction is used to upload data onto the ledger, it still must contains a payment that transfers the ownership of at least one satoshi from at least one input to at least one output.

To illustrate this process, we'll use a hypothetical scenario where Alice pays Bob for her coffee. Bob owns a coffee shop and accepts payment using CBDCs.

1. Alice orders her coffee at the counter.

2. Bob provides Alice with an invoice that includes a template transaction where Bob has pre-filled at least one output (including a value) to accept payment.

3. Alice fills in at least one input of the transaction template using one or more UTXOs she owns or controls to cover the cost specified by Bob in the output.

4. Alice will then returns the now filled in transaction template to Bob along with the Merkle Paths of the transactions from which she pulled her transaction inputs from (this can be made much easier if Bob and Alice use the Background Evaluation Extended Format (BEEF) format in their transaction template: see BRC 62.

5. Bob receives and validates the transaction by performing Merkle proofs on all the provided inputs and comparing the results against his copy of the chain of Block Headers. At this point, If this is successful, Bob could give Alice the coffee and Alice could be on her way since the risk Alice is defrauding Bob is very low with a simple cup of coffee.

6. Bob then submits the transaction to an Overlay Service that accepts the utilized transaction type (in this case a fiat transaction type) be timestamped.

7. The Overlay Service receives the transaction and performs the same validation Bob did as well as additional validations relevant to the transaction type (for example, in this case, checking against a law-enforcement provided list to see if any of the input transactions have been involved in a crime and are being monitored). Once the Overlay Service is satisfied, it updates its internal state and provides a confirmation to Bob and submits the TX to the Node Network.

8. The Node then performs its validation checks and if approved, adds the transaction to a Block Template.

9. Within a second, the Overlay Service can send a lookup request to a UTXO Lookup Specialized Service to confirm the transaction has been accepted. It then relays this full confirmation to Bob.

10. Once the transaction has been timestamped in a block, a Merkle Specialized Service provides the Overlay Service with enough information to construct the Merkle Path of the transaction.

11. The Overlay Service then provides the Merkle Path to Bob, and if Alice added an output to the transaction template, Bob forwards the Merkle Path to Alice so they can both use the UTXOs they control in subsequent transactions.

Notice that Bob doesn’t need to wait for the transaction to be timestamped. He can either approve the payment instantly using only his local SPV check (0-conf) or he can wait a few seconds to confirm the transaction has been accepted by a node (seen-conf).

This is possible because the first-seen rule ensures that once the payment is seen by a node, any double-spending attempts will be rejected by the nodes in the network.

Infrastructure Requirements

The three elements needed by Bob and the Overlay Service in the above example are:

Block Headers - 80 bytes per block × 52,416 blocks per year ≈ an increase of 4.2 MB per year

Transaction data - about 400 bytes for a simple p2pkh transaction where the input's TX has been mined

Merkle Path(s) - Approx. 1 KB per path assuming 4 billion transactions in one block

Transactions are a means to create entries on the Bitcoin Ledger. This section explores the Simplified Payment Verification process in-depth, its usage in front-end user applications known as SPV Wallets, and back-end provider applications and services known as Overlays.

Nodes in the blockchain network are enforcers of the rules on all transactions that are produced by the network. The ones that pass the ruleset are then added to the new block, becoming immutable history of recorded data. Nodes, however, do not make new rules or arbitrate in terms of what goes inside the transactions.

Nodes are also typically businesses who, as you can see by now, not just need to run expensive hardware but also need to constantly keep upgrading it so that they are able to compete within the growing needs of the blockchain network and what other competitors are doing. They also will possibly invest in software improvements and provide various blockchain related services, which can act as an additional source of income for them. This means that when an entity undertakes the work of running a node, they should be quite public in terms of their operations and always a legal business entity so that they accountable to the jurisdiction they are operating in. This is often overlooked aspect when it comes to blockchains and nodes running them.

But a blockchain like BSV Blockchain, which requires quite a significant amount of infrastructure not just for PoW process but also for the storage of large blocks, would require a node operator to invest large cost of setup just to get started. Such operations will always end up in data centres or consuming large cloud infrastructure; either of them requires them to be disclosing their legal taxation and identification information. This is intentional, as all this makes these nodes public entities known to the jurisdiction and accountable for what services and operations they perform. This is quite critical for implementing freeze and recovery process of stolen coins and performing pruning or any censorship activities as required by law on the blockchain.

Transactions are at the heart of the blockchain network. Every transaction that happens on the network modifies the state of the blockchain.

The purpose of the bitcoin protocol was to redefine the methods and ways our lives use the internet by adding the missing link of secure, small, casual, payment infrastructure to it. It additionally provides a system of recording data using a native commodity token system.

This base system can become a central global public timestamping system for all information and data transmission. A transaction can encapsulate all types of interactions.

The main purpose of the Block Assembler is to take the list of validated transactions stored by Mempool for its consumption and creates a fresh block template data structure to add transactions. It orchestrates block-template creation by talking to Chain tracker, Mempool and UTXO Store. It also performs basic checks on transactions before they are made part of the block template, including updating the transactions and UTXO status.

The ChainTracker provides the Block Assembler with the current Chain-tip. The Assembler then builds a new block on that tip by first fetching all the verified transactions present in the mempool. It then constructs the Merkle root value by ordering all the transactions in first-seen order and building a Merkle tree root value from the transaction ids. Once the value is calculated, it will construct the block header based on the current difficulty value.

In parallel, the mining pool software is constantly communicating with the Assembler to keep retrieving the latest mining candidate. It will keep responding to the mining pool calls and keep providing it with updated block candidate headers and mining candidate values (see mining topic for more details).

Even though mining provides one of the most critical components of a Blockchain, its process itself is quite decoupled from rest of the node software functionality. The connection is made by Block assembler, who prepares the Candidate block and its header as part of its work and then feeds what is called as a mining candidate to the mining pool software.

The mining pool software controls either a centrally located datacentre of ASIC machines or even, at times, machines that are distributed across the internet. Once the mining pool receives the mining candidate, it will start the proof-of-work calculation process to find the solution for the next block hash.

The mining software currently uses ASICs, specifically designed chips for calculating SHA256 hash values for a proposed block header. They perform a brute force-like calculation constantly to randomly hit the target set for achieving the solution for the proposed block hash. This is approximately explained in the diagram below.

The candidate block header is hashed using a SHA256D (double SHA256 hashing) to calculate a proposed value. This value is then compared with a target. If the calculated value is less than the target value (identified with leading zeros in the value), then a solution is found. If the value is more than the target value, the nonce is incremented to a new value so that the result of SHA256D(Block Header) is a new value. This process is repeated constantly by the mining chips. Once the solution is found, it is passed back to the Block Assembler, which then will inform the ChainTracker and BSN that a new solution is found locally, and this now needs to be propagated to the rest of the mining nodes in the network.

When other nodes receive an intimation from this node about the proposed block, they will trigger the Block validation process at their end to validate if the proposed block is a valid block. If the block validation is successful, they will then update their chain-tip ID with this proposed block as the most recent block. They then will start building a new block with this Tip ID as the longest chain, and if they find a solution, it follows the same process described above. This is something that is constantly occurring in the blockchain network, making it a very time-bound and hard-to-reverse process for nodes.

If they go offline, even for a small-time frame in this process, they will be out of sync with the ongoing proof-of-work process and the block height that they are on. Joining back then will require them first to download the blocks created when they were offline and then start to mine a new block.

Orphan Blocks

As described in the process above, there are situations in the process of nodes proposing a block where more than one find a solution at the same time. This could create a temporary situation when there are multiple chain tips that are considered the longest chain by different nodes, and they build on it. The situation resolves itself when the next block is found on a given chain tip by the same or another node making it the longest chain. This process again goes on repeatedly. The temporary situations where two or more chain-tip are recognised and resolved by the discovery of the new proposed block will result in abandoning the chain-tip, which does not get the new block built on it. In this scenario, the block, which at the time was a successful solution but loose out due to another node finding a solution, gets orphaned and is later deleted from the network.

Invalid Blocks

If a node proposes a block that fails Block Validation, the proposal is ignored, and other nodes continue trying to find a valid block which builds upon the previous valid block. A node may consider a block invalid due to numerous reasons, including:

• The block fails a consensus rule (e.g. over size)

• The block awards the miner too many bitcoins

• The block contains an invalid transaction

• The block does not include a valid proof-of-work or timestamp

In a situation where a node has submitted an invalid block, the block is rejected. If the node submits multiple invalid blocks, other nodes on the network may take additional steps, such as blocking the node’s IP and refusing to share network information. Typically, these ‘bans’ take place over a 24–48-hour period and are intended to make node operators aware of repeated mistakes. Each node can set its own policy in this regard.

It is important to understand that nodes on the network are free to accept or reject blocks from any party for any reason. It is upon each node to ensure that they are aware of what the majority of nodes on the network have accepted as the valid chain of events. This is so that they can always be building on the longest valid chain of blocks and minimise resources used working on blocks the network will refuse to accept.

When a new transaction arrives at a node, it goes through a set of checks and validation rules. These are the consensus rules a node is mandated to enforce for the network's operations. Most of them are standard across all nodes and are part of the Bitcoin protocol (shown as Standard Policies in the diagram below). Node’s also apply local policies which are specific to their own infrastructure and preferences.

Generally, the rules for Local Policies are only checked for transactions before they are accepted into the mempool or included in the block candidate. In contrast, Standard Policies or consensus rules are always checked.

Block validation process involves validating a block and its transaction data along with the chain-tip which the block is being added to. Block Validation is done when the ChainTracker gets informed of a new proposed block or when there is a new node set-up being done requiring node to build history in sync with the current chain tip. The main functionality is that the provided block is validated in terms of block metadata and underlaying transactions, all being correct.

When BSN is informed from other nodes about a new proposed block, it will trigger the validation process for that block. Firstly it will interact with the chain tracker to get the internal chain-tip details and then get the process of block download done to receive the block proposed by another node. Once the block is downloaded, its validation will be done by the block validation process. Block validation will do both, validate the block metadata and ensure that it is valid, and then validate every transaction present in the block. Typically about 97% of the transactions in the proposed block should already have been validated by the node as part of building its own block and that confirmation is received from the mempool for the larger set of transactions. The remaining transactions that have not been seen by the node, are then given input to the transaction validation process which will validate and verify if these transactions are valid. Once done, the validation process will calculate the Merkle tree based on the transaction list to validate it against the block header values. If everything is successful, the node will accept the block as valid and start building on top of this block. The chain tip tracked by chain tracker will also be updated to reflect this change.

Another important feature of Simplified Payment Verification is confirmation of instant payments.

As described earlier, Bob uses the node to get a payment acknowledgement to ensure transaction's validity accepting it. This is where the node performs validation steps on the raw transaction involving validating the script that is present in the unspent UTXO and the signature that is provided by Alice and executing both the input and output script as described in Transaction Lifecycle.

Why is Bob able to trust the system for instant transactions?

The answer to this lies in understanding what Bob is doing when he receives the transaction data and Merkle proof mentioned earlier.

Transaction Data

The transaction data that Bob receives has the raw payment transaction, the Merkle Proof of the previous transaction and the previous transaction itself.

As described above, steps 1,2,3 and 5 are performed locally by Bob, which means most of the error scenarios for an invalid transaction are performed locally by Bob, effectively making this process independent of any node.

Step 4 can also be done by Bob, however, he will need an additional component for running and executing script validation. The component comes as part of node software, and that is why in the above scenario, Bob delegates this check to miners, as even if Bob performs script validation locally, he is still dependent on nodes to provide a double spend check.

The signature present in the input is a digital signature. This is analogous to the signature required by merchants when accepting credit cards, where you are required to sign the receipt and match that signature with the signature present on the card. Digital signatures have been considered legally binding for more than a decade in most countries. Therefore, if the digital signature present in the transaction is valid, that can provide the required remaining trust in the transaction presented to the merchant (just like for credit cards), and this effectively can make payments safe and instantaneous.

What happens when the digital signature is verified?

Th following diagram provides a high-level illustration of the digital signing process.

This process comprises the following components (see Privacy for a more detailed description of the process):

• Signed message

• Digital signature

• Public Key

As illustrated in the previous diagram, the digital signature and public key are provided in the transaction input. The signed message is constructed by the information provided in the transaction and the Merkle proof (during the execution of the validation process). The message itself looks like this:

The colours indicate the location of the information in the payment and previous transactions. An algorithm is used to carry out the processing and construct the message based on the Sighash flag value (All, none, single selection of Inputs and modifier, ANYONECANPAY).

In the diagram, the flag assumes the value -SIGHASH_ALL | ANYONECANPAY.

As you can see, the constructed message requires not only the integrity of the previous transaction script but also the the UTXO amount. To ensure its integrity, it also takes the required fields from the current transaction. When this message is signed, this ensures not just the signature’s validity but also the integrity of the transaction outpoint being spent along with the current transaction’s validity.

Instant payment can be achieved if the verification of the signature is correct. In doing so, the message uses information from both the previous transaction as well as the current payment transaction, ensuring the integrity of the spending method. If Bob does this locally, he can be very sure of the payment and signature is valid, and he can accept it as safe. If he is delegating the signature validation node, then he has to wait to receive the response from the node before he can accept the payment as valid.

To summarise, verification of the digital signature requires the following:

• the message to be signed

• the signed message containing some data from the previous transaction i.e. the value and the locking script

• the integrity of the value and the locking script

The Simplified Payment Verification check can provide integrity for all the data in the previous transaction.

As the merchant, Bob can accept payment directly from Alice (peer-to-peer, possibly offline) and be confident that he will not be cheated by Alice by performing a Simplified payment verification process check.

This process is effectively instantaneous and with every payment being settled on the blockchain, safe and secure. The time taken to confirm payment contrasts with a traditional payment network where settlement can typically take anything from a few hours to several days.

The first two features of SPV were to verify the presence of transaction on the blockchain for the previous transaction, which created the UTXO being spent and the input UTXO containing a valid signature. But even if these two aspects are validated, there is still one more integrity check required, which is the integrity of the locking script for the digital signature performing the intended function. The locking script dictates the unlocking script, and it should contain the right requirement of a digital signature for the full integrity of the transaction.

Here the full integrity means that Alice is digitally signing the ownership of funds to Bob.

Let's view this in terms of these example scripts.

Previous transaction’s Locking Script:

Input (Unlocking) Script:

The locking script requests the spending input script to have a digital signature signing the funds from Alice to Bob (via the singing of public keys).

Let's take another example:

Previous transaction’s Locking Script:

Input (Unlocking) Script:

As this example demonstrates, any valid pair of signature and public key will make the transaction valid. This breaks the integrity of the transaction in legal terms required by the digital signing process. So, Alice could not have been the intended recipient and the rightful owner of the funds from the previous transaction but is spending it because she can, and Bob potentially could have received stolen funds.

Another such script example is:

Locking Script:

Unlocking Script:

Any pair of strings will make the transaction valid, and the integrity of the digital signature is not protected.

To summarise, the integrity of the locking script is a critical element in proving the integrity of the published transaction. It's integrity is ensured by:

1. specifying the public key

2. explicitly requiring a digital signature

When the integrity of all three SPV processes are ensured, true peer-to-peer payments, that are secure and effectively instant, are possible.

SPV systems are applications that are quite small and basic and, although this example demonstrates a payment application, similar applications for data transactions can be built using the same concepts and ideas. These applications are called Light Clients and the infrastructure design is referred to as SPV infrastructure.

A transaction is a standardised data structure encoding an ownership transfer of some amount of digital commodity tokens (satoshis) from one party to another. At a high level, each transaction comprises inputs and outputs.

The inputs of a transaction consist of the following information:

1. The TXID and output index of the UTXO being spent .

2. The requisite unlocking condition(s) that authorise the sender (i.e. the first party) to transfer ownership of the asset (i.e. spend it). This can be any message or data that satisfies the locking conditions of the UTXO such that the added information makes the UTXO locking script evaluate to TRUE.

The outputs of a transaction each specify the following information:

1. A recipient (i.e. the second party) to whom the ownership of the commodity tokens(s) is transferred.

2. The locking condition(s) that specifies how the recipient may subsequently unlock, and thus ‘spend’, the digital asset.

Each transaction to be recorded on the blockchain ledger is assigned a unique identifier (a Transaction Identifier or TXID).

The nature of the unlocking process depends on the locking script used when the output was created in the previous transaction.

There is no practical limit imposed on the number of inputs or outputs a transaction can contain, but the technical limit is about 2 raised to 32 inputs. The transaction size limits imposed by miners will come into effect before the number limit is reached.

The overall data structure of a transaction is shown in the following diagram.

Let us look at a more realistic scenario of a transaction which involves spending of funds using digital signatures. Consider a timeline with three timestamps, t1, t2, t3, where transactions T1, T2, and T3 were recorded in blocks B1, B2, B3.

• Transaction T1 represents a transfer of funds from Alice to Bob; Alice has 51 BSV and transfers 50 BSV to Bob;

• Transaction T2 represents a transfer of funds from Bob to Carol; Bob has 50 BSV received from Alice and transfers 49 BSV to Carol.

• Transaction T3 represents a transfer of funds from Carol to Dave; Carol has 49 BSV received from Bob and transfers 48 BSV to Dave.

Alice, Bob, Carol, and Dave have their private-public key pairs as [k_pr A, k_pub A],[k_pr B, k_pub B], [k_pr C, k_pub C],[k_pr D, k_pub D] respectively.

The image above includes the following:

1. Locking script of T1 locks the fund transferred to Bob

2. Unlocking script of T2 unlocks the locking script of T1

3. Similarly, the locking script of T2 locks the fund transferred to Carol, and the unlocking script of T3 unlocks the locking script of T2

All Transaction Inputs are inextricably associated with the previous transaction, and all Transaction Outputs will contain details of the conditions which need to be satisfied for future spending. An easier way to understand this would be to view it as analogous to transferring fiat currency in the current financial ecosystem. When a conventional currency transfer occurs, there are two parts - the amount is debited from a payer's account and credited to a payee's account. In bitcoin, 'debited from' (payer) details are contained in Transaction Input, and the details of 'credited to' (payee) are included in Transaction Output. The difference here is that Transaction Inputs have information on the source of the funds. For example, consider transaction T2, where Bob transfers funds to Carol. Transaction Input of T2 will be associated with previous transaction T1, i.e., transaction via Bob received funds from Alice.

The output only contains the amount, so the next question is, how is the identity of the payee associated with the output?

A transaction output contains a lock on the funds by associating it with a specific public key of the recipient of funds. In other words, the payee's identity is associated with the public key and provided in the locking script. The fact that public keys are used for identifying the user, and a user can generate as many fresh public-private key pairs as they like enables pseudonymity in public blockchains like BSV. To spend the funds further, it becomes imperative to sign the funds using a private key. Hence, the public key and signature are included in the script as well as the operand to verify the signature. Once the digital signatures are used, they intricately bind the identity of the person with the funds.

For example, to make a payment transaction from one key pair to another. The key-pair provides a mechanism to demonstrate control of assets in the same manner as property rights, i.e., purchase records, invoices etc., are needed to prove ownership of funds locked with the key-pair. The Owner signs the funds to a new owner (owning the new key-pair) via a digital signature which is then added as a data element in the input script. It also locks the funds in the output to the new Owner’s public key which will in turn require the new owner to perform digital signing and hence irrevocably binding their identity again with the transaction recorded publicly on the blockchain.

Both the input and output contain a program/code written in a new programming language known as Script. The script associated with the transaction output locks the funds, and the script associated with the transaction input unlock the funds. The vital point to consider is which 'funds' do the transaction output lock and which 'funds' do the transaction input unlock. The unlocking happens on the outputs from previous transactions, which are committed to be spent in the current transaction. The locking happens on the outputs of the spending transaction such that the balance can be secured by the script until the party with the correct solution can provide it when they are used as an input in another future transaction.

Script, is a low-level programming language very similar to assembly-level programming coded using operational codes or opcodes (186 in total), which can provide for coding all types of business logic commonly known as “Smart Contracts”. The term ‘Smart’ refers to developers' ability to program logic in transactions allowing programmable contracts. Typically, the output script will lock the funds with certain conditions, and a later transaction will unlock the funds by providing the answer to the specified condition.

For example, let's say we create a transaction where the output will lock funds by a program written in Script, which is – “what is the answer to math equation, 1+2”. The answer to this ‘puzzle’ is 3. So, the next transaction which intends to spend this UTXO, will need an input which provides this answer, “3”. When the transaction spending the funds is submitted to blockchain, the validation process will combine the Input (Answer, 3) with the original question present in the output of last transaction, (what is the answer to math equation, 1+2) and execute this combined sequence of instructions to arrive at a single answer, true or false. The nature is script is such that it will always result in a true or false answer, and due to that is also sometimes said that script is a “predicate”. The compiler (termed as Script Engine) is built such that it uses a stack for the execution of the instructions (op-codes and operands).

As shown on the left side of the diagram, the validation process will validate all other fields and then construct a script evaluation input for the script engine. This script evaluation code (input unlocking funds from locked output script) looks as shown in the diagram (right) for the above example. Internally the compiler uses a data structure called stack for evaluating script execution. It identifies data elements and opcode or operation elements in the Script and acts based on it. If it is a data element, it is pushed on top of the last element in the stack. If it's an opcode, the compiler will know how many operands it takes, so it will take that number of operands from the stack out, apply the opcode to them and store the result on top of the stack. This is demonstrated in the diagram. It will keep doing it until no more data or opcodes are left to execute. The final state of the stack will be the evaluation result of the Script, always a Boolean, in this case, true.

Transactions are grouped in blocks and processed together. Therefore, to understand how transactions are processed, we also need to understand how blocks are created.

As described earlier, every node in the network competes with other nodes to be first to solve the PoW solution, which means that every node has prepared a candidate block to use its header values for the PoW solution. This also means that when a node proposes a candidate block, they send that proposed block to every other node in the network so that they can start building on it and effectively making the proposed block a consensus-approved history in the blockchain.

This process is described in the diagram below. Node A proposes a block. This is done using the Bitcoin server network (BSN) where the node first sends a message informing all the other nodes that a solution to POW has been found and, if they have not found a solution themselves, to take Node A's block. If the validation is successful, nodes can start to build on this block.

The nodes receiving the message from node A will send a response back intimating that they have not yet found a solution and are willing to receive the full block message from node A. Node A then propagates the full block to these nodes.

When these nodes receive the block from node A, they validate the block (perform a block validation process), and if they find the block to be valid, they signal their acceptance by restarting their POW process to find the block next to the block received from node A.

1. Node A proposes a block by sending a message on the Bitcoin server network (BSN) informing all of the other nodes that they have found a solution to PoW, and requesting them to take their block.

2. The nodes receiving the message from node A send a response back informing that they have not yet found a solution and are willing to receive the full block message from node A.

3. Node A then propagates the full block to these nodes.

4. When these nodes receive the block from node A, they validate the block (perform a block validation process).

5. If they find the block to be valid, they signal their acceptance by restarting their PoW process to find the block next to the block received from node A.

The block validation process will also have a step where all of the transactions present in the block are validated. These transactions then become part of the block proposed by Node A and will become common history, timestamped with the time node A built the block.

The following diagram shows the complete end-to-end flow for this process and simulates a client-server model. In this, the users who create transactions are the clients, and the node network acts as a server receiving transactions from their clients.

These server nodes then compete and cooperate with each other to come to a consensus on a common history of accepting a candidate block.

This process is repeated on average every 10 minutes. This interval is configuration-controlled and maintained by the difficulty adjustment algorithm. This number of 10 mins is something that is a guess in terms of it being the optimal interval, but the guess is based on mathematical calculations.

The validation of a transaction can be seen as a set of steps that happen when a node receives a new transaction.

Transaction Storage

When transactions are received by a node, they are first parsed and then checked to ensure the input/output script size are within limits and the tx size is acceptable. A check is also made to see whether the transaction has not already been seen by the node. Once all these steps are complete, the transaction is stored in a key-value database.

UTXO Storage

Every transaction on the blockchain changes the state of the blockchain due to the UTXO set that each node stores. These UTXOs are first stripped from the stored transaction, and then various checks are made. If everything is ok, these UTXOs are locked to be spent and stored in another database (key-value) with a status of ‘locked’. This means that the change of state caused by the block this node will propose will consider the change made by this transaction as an update to the UTXO state of the blockchain.

Transaction Validation

Validating a transaction requires a series of steps to validate various consensus and policy checks, execute the scripts present in the inputs and outputs and, based on the result of execution, store the final state of UTXO.

The validated transactions are then stored in a cache database, which is called mempool.

Block Assembly

When a block is to be proposed by a node, they will collect all the transactions present in the mempool and create a candidate block. The various steps in this process are as follows:

• Preparation of a block template with current network parameters

• Identification of the longest chain on which the candidate block needs to be built

• Collecting all of the transactions from the mempool

• Adding the Coinbase transaction

• Transactions Merkalised

• Creating candidate block header

• Passing the candidate block header to the mining pool component to perform the PoW

Block Validation

Once the PoW solution is found, the node will propose the candidate block to all of the participating nodes in the network. If the the PoW solution remains undiscovered by the other nodes, they will accept the proposed block and validate it. As well as the validation of block parameters, the validation process will also include validating the transactions that are proposed in the block. If the validation of the block is successful, they will treat this block as the chain-tip (so called as it is the latest block in the blockchain) and start to build their own new candidate block on top of this tip. This effectively means that they have voted to choose this block as a valid block.

Once the majority of nodes which are building the next block on the chain-tip find the PoW solution built on this chain-tip, this will effectively finalise all of the transactions present in the block as valid history. This point marks the conclusion of the transaction processing lifecycle.

It's possible that a transaction can be marked as double spent. This happens when the same funds are being spent twice. This should be caught during the transaction validation done by the node and is decided based on the first-seen rule. See the First Seen Rule for further details.

As shown in the diagram, the UTXO N-1 is spent in Input, transferring funds to a new owner, in this case, Dave, as shown in Tx3. Dave creates Tx4 to spend the funds he received in Tx3 shown as UTXO N . When Dave submits Tx4 to a node, and the node accepts it, the UTXO N is marked as spent in the UTXO database of every node. So, if Dave tries to spend the same funds (UTXO N) again to Charlie in Tx5, it will fail validation as the UTXO is already marked spent due to Tx4. This is known as First Seen Rule in the network and it means that once a UTXO is spent, any other transaction received by the network spending the same funds again (i.e. double spend) is rejected.

Block Confirmations and Merkle Proof

Once a block is accepted by the node network, all of the transactions in that block get their own Merkle proof. A Merkle proof is a set of values in the Merkle tree which, along with the transaction id, can provide for the independent calculation of the Merkle root present in the block header. Once a block is confirmed the node can provide the values known as Merkle proof (standardised format for Merkle proof along with block and transactions details) for a transaction.

This is the last piece in the transaction lifecycle. The diagram shows this process.

Each transaction has its own Merkle proof. This can be thought of as a Blockchain certificate for that transaction.

Transaction Finality

Transaction finality is an important attribute which means that the funds are locked to the new owner, and the record is frozen. In financial terms, this is known as settlement. In an account-based system offered by financial institutions, all individual transactions are collated, and a final amount to be exchanged between two financial institutions is calculated. This process is called netting/clearing. The final settlement happens when this netting amount is exchanged between the two institutions.

The decentralised component of blockchain occurs when Alice and Bob exchange (P2P). Alice and Bob exchange a transaction between themselves, not via node as intermediary. Details including digital goods can be incorporated into the exchange. Invoices, digital asset files, and things can be directly exchanged between Alice and Bob. Bob then registers the exchange receipt and finalises it by sending it to the node (via transaction).

In the UTXO-based model, clearing and reconciliation (for example this is done by banks when they do payment transactions) is not required as every transaction is a full and final exchange between the two transacting entities and not the financial institutions. This is a vital aspect of why a UTXO-based payment system is more scalable than an account-based system. As soon as it is accepted by one or more nodes, the transaction is considered to be in a 0-conf (or zero-confirmation) state. In other words, it is still regarded as unconfirmed as it is not yet part of a confirmed block but is now seen by a node and is part of the mempool of that node.

As we have explained, transactions are not always used for exchanging value in the blockchain. Still, the primary use case is for transactions carrying information (data) which involves an extremely low value associated with the transaction, most times just enough to pay the fees for the transaction. These low-value transactions, when accepted by a node as part of 0-conf, are considered economically safe to be assumed Final. This is because the economic incentive to double-spend on such low-value transactions is largely negative. In fact, in most realistic scenarios, close to no possibility. We will discuss this more in the Security section, where various attack scenarios are explained and, with that, why as soon as a transaction is accepted by a node or 0-conf, it is considered final.

Transactions can be formatted in specific ways and/or use specific values to create transaction templates.

The following are useful constituent parts of transactions that can be used to construct transaction templates:

• Version field: A 4-byte field that can be used to denote a version or template.

• Script: A programming language which allows custom logic to be added to locking scripts.

• Hashing and elliptic curve properties: Keys and hashes can be combined or augmented such as with Type42 (provide link) key derivation trees

• nLockTime and nSequence: Allow payment channels, negotiations, and time locks.

• Sighash flags: Allow certain parts of a transaction to be signed while keeping other parts unsigned so they can be updated without invalidating the transaction (find out more here) (link to sighash flags).

Transaction Template example : Pay-to-Public-Key-Hash (P2PKH)

"Pay-to-Public Key Hash" (P2PKH) is the most widely used template.

To provide some insight into what the script looks like, below is the unlocking and locking script of a P2PKH script:

Previous Transaction Output
Locking Script - OP_DUP OP_HASH160 <Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG

Current Transaction Input
Unlocking Script - <Signature> <Public Key>

<Signature>, <Public Key>, <Public Key Hash> are operands and the remaining are opcodes
Note: The opcode OP_CHECKSIG performs a digital signature verification

When Alice transfers the fund to Bob, she will construct the script that will create the script shown above as the Current Transaction Input which along with the Previous Transaction Output becomes the full script that goes as input to the script engine and its execution is shown in the animation below.

As shown first, the operands, Alice’s signature and the public key to which the funds were locked (present in the current transaction’s input) will be put on a stack.

Then the OP_DUP opcode is processed, which will duplicate the top item on the stack, the public key of Alice.

The next opcode is OP_HASH160 which, when applied to the public key, produces a 160 bits hash value of the public key. It is the same value the funds would have been locked to in the previous transaction, as shown as the next operand put on the stack.

When OP_EQUALVERIFY opcode is processed, it will take the top two items, both in this case, public key hash, and compare them; if they are equal, they are removed from the stack.

The last opcode is OP_CHECKSIG which performs a signature verification (explained in detail in the Cryptography section) and if the signature is valid, the result, true is returned as the final output of the script execution.

Another slightly different variation of this is a P2PK or pay to public key where in place of hash the public key is used as is.

Transaction Template example : Multi-Signature Transactions

Also knowns as P2MS - Pay to Multi Sig transactions.

A typical transaction input requires one private key (i.e., one signature) to spend it. However, it is possible to lock coins with a requirement that more than one signature must be provided before the coins can be spent. Script offers OP_CHECKMULTISIG opcode to implements a scenario where m private keys out of a possible n (m <= n) are required to move the coins. Transaction outputs with OP_CHECKMULTISIG are usually denoted as Pay-to-Multi-Signature or P2MS.

For example:

Locking Script: OP_3 <pubKey1> <pubKey2> <pubKey3> <pubKey4> <pubKey5> OP_5 OP_CHECKMULTISIG

Unlocking Script: OP_1 <sig1> <sig2> <sig4>

In the above example, the scriptPubKey says that 3 out of 5 possible signatures are needed to spend the coins. The 3 signatures in the scriptSig must be placed using the same order in which the public keys are arrayed in the scriptPubKey. Note that there is an additional value OP_1 at the beginning of the scriptSig. This value won't be evaluated (therefore, any piece of data can be used here). It is there to “fix” a bug in the current implementation of the scripting engine where OP_CHECKMULTISIG removes not only the required parameters but also an extra unnecessary value off the stack.

A truly global blockchain is one where the blockchain network not only demonstrates a large transaction processing capability, but it is also able to account for how it can scale.

Something that is commonly misunderstood concerning blockchains is that businesses and users who want to utilise blockchain for their applications need to run a node. This puts a heavy infrastructure burden on businesses and developers who want to build Web3 solutions.

Satoshi Nakamoto -

"The design outlines a lightweight client that does not need the full block chain. In the design PDF it's called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can't generate blocks. It does not need to trust a node to verify payments, it can still verify them itself.

The lightweight client is not implemented yet, but the plan is to implement it when it's needed. For now, everyone just runs a full network node.

I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.

At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN."

With SPV Wallets and Overlays, there is no need for a business to run a node.

In terms of network topology, P2P interactions coupled with the ability for receivers to do local verifications, pushes the bulk of network activity to the edges which greatly distributes and localizes network load and data storage needs.

There are no strict definitions of what a light client should be designed as except for the fact that these applications will typically be either running the SPV infrastructure themselves or they will connect to service providers who do it on their behalf. This makes every application that is not a node creating blocks a light client. The term 'client' is analogous to the client role in client-server architecture used in web applications where the central node network acts as a blockchain server, and every other application becomes its client.

The overall view of the blockchain network will show the network having only a small number of nodes at the core. Most of the other applications will function as light clients.

The diagram shows the overall network topology identifying everything except from the nodes as light clients.

What will these applications look like?

Applications, whether they are hosted in a data centre or a cloud platform, will include some components which allow them to interact with blockchain. Note that these applications will predominantly be focused only on submitting transactions to the blockchain to be timestamped. They don't need to read from the as they can store all of their transactions and corresponding Merkle Proofs themselves.

The infrastructure requirements of a client application’s blockchain are:

1. An SPV Wallet with, at minimum, the following capabilities:

   1. Key Management

   2. Digital Signatures

   3. Wallet functionality like backup and storage of keys, user identity and data

   4. Transaction Manager

   5. UX/UI as per feature requirements

2. Overlay service or component (could be part of wallet itself)

   1. Transaction validation (SPV plus further validation logic as required)

   2. Transaction broadcaster to nodes

   3. Merkle proof retriever and storage

   4. SPV process validator

   5. Signature and script validator

Currently, most of the nodes provide API endpoints that allow transaction and UTXO lookups. However, with the advent of Teranode and the Mandala network topology, Nodes will no longer provide these APIs; instead, this access will be provided by Specialized Services which are services that live within the node level, but are not part of node operations. The two Specialized Services required for SPV are the Merkle Service and the UTXO Lookup Service.

Merkle Service

The Merkle Service will take in much of the same information nodes do such as sub-trees or partial Merkle trees which it will use to create the top section of Merkle Paths for every block. Overlay services can then build on this information to construct complete Merkle Paths which they can then forward to SPV wallets to be used in future transactions.

UTXO Lookup Service

The UTXO Lookup Service is another Specialized Service that follows the activity of nodes by keeping tabs on what the current state of network UTXOs is. Overlay services can then send lookup requests to UTXO Lookup Services to find out what the current state of the UTXOs they care about is, and update their local UTXO stores accordingly.

The Bitcoin Association provide a reference implementations as a starting point for such infrastructure. The following diagram provides an overview of this implementation.

The SPV Wallet and Overlay Services reference implementations provide the necessary components needed for businesses and developers to start using SPV, timestamping, and micropayments/microtransactions in their applications:

• A simple web wallet

• Block headers client

• A transaction builder and broadcaster

• ARC (A broadcast client)

• Paymail (a user readable email like address to simplify public key usage in user experience)

• A complete library for performing most of the SPV processes and wallet functions

Every input in a transaction contains a field titled nSequence. This is a 4-byte field, i.e., it can hold 2^32 values (0x00000000 to 0xFFFFFFFF). nLockTime allows for the creation of a transaction which will only become valid at a future date and time specified in the field or at a specified block height. Once the date/time mentioned in the nLockTime happens, the transaction, even if it has a non-final state due to a lesser than maximum nSequence value, will be considered final.

Sequence numbers are designed to be used for transaction updates before it is finalised. For example:

• Alice sends a transaction where the nLockTime value is set to a date in the future. It can start at an arbitrary future date, but by convention, it starts at 0.

• The miners will not recognise the transaction to be valid, and thus, “final” until the nLockTime value has either been reached or set to UINT_MAX: 0xFFFFFFFF. As a result, the transaction will not be included in a block. Most often, this will mean the nodes will drop the transaction as they have no incentive to store it until it is final.

• As the transaction cannot be included in a block until the time specified in the nLockTime is reached, there is a final state that both parties have agreed to and also the ability to send updated transactions. If there is a 2-of-3 address (known as multi-sig), the parties can use an escrow (such as a licensed shared registry) to ensure that a transaction that has been agreed is final. If not, we can also have the parties negotiate and allow a means to “pull out” of the negotiation at any time before the nLockTime deadline. This means if any party tries to submit the transaction, it will not be timestamped into a block.

• Using this method, and prior to when the set nLockTime is reached, users can replace the transaction with a higher-version transaction.

• The negotiations can also be finalised. If a party sets the sequence number to UINT_MAX, the transaction is considered as being finalised by the miners. No replacement can occur. When the sequence equals UINT_MAX, miners will no longer accept a replacement transaction even where the nLockTime value remains in the future.

• If you ever want to lock the transaction permanently, you can set the sequence number to UINT_MAX. Then the transaction is considered to be final, even if the time represented in nLockTime remains in the future.

This feature allows negotiating parties to create and sign a prepared transaction.

• These prepared transactions can be negotiated, agreed, and signed by the the parties allowing them to move money between each other. This can allow for a base agreement and payment stream. This is conducted securely and without fees — the fees paid are to the miners for the settled transaction, not the exchange.

• Extending this would allow for a range of services to be created that involve users withdrawing and depositing funds into a service without waiting for confirmations.

• If the user breaches the contract, the final transaction could be signed with an escrow to ensure compliance and prevent theft.

Now that we've looked at the various aspects of identity and privacy in blockchain, let’s examine how these attributes are achieved when designing a blockchain system using its underlying capabilities and features.

The transactions in a public blockchain are not private as they are published on a public ledger in cleartext. It is done in this way in order to solve one of the biggest yet seemingly unsolvable problems of double spending with digital cash systems. By creating a system that publicly announces all transactions that can be viewed and analysed by anyone at will, any attempts to double-spend funds are identified and documented on an immutable public record.

Does this mean the identity of the parties to a transaction are made public?

Whilst a transaction contains the public keys of the transacting parties, there is no information specifically that could enable identification of the individuals to whom the keys belong.

Privacy is part of the core design and basic infrastructure of a UTXO-based blockchain, but care must be taken to ensure that it is maintained. If the ownership of keys is published publicly (on-chain or off-chain), the information present on the blockchain will no longer be private. But if the identity is protected and not exposed, this creates a private system.

Privacy on the blockchain is also governed by volume. The greater the number of transactions going through the network, the more private the network will be. If, for example, there are just 10 transactions it would be quite easy and relatively inexpensive to trace through the transactions compared to say a billion transactions which would make traceability very expensive.

When building applications, an analysis needs to be made on the usage requirement and how to achieve the required privacy.

With data transactions, it is quite easy to achieve privacy by creating transactions with just enough funds to pay the fees for the transaction.

When transactions involve payment or script-based electronic contracts, use of a new key-pair will provide the required identity firewalling or any personally identifiable information. In addition, when the blockchain is being used for high value payments which could potentially expose information that, when tied in with other private details, could reveal ownership information to the public, it is advisable to split the keys into a sufficient number of small units such that it obfuscates details of the payment value.

These are some of the different options available to protect privacy on the blockchain.

In the new model of trade specified In the Bitcoin protocol’s description of privacy, this is described in the white-paper as fire-walling identity. It has been sometimes misinterpreted as being anonymous.

The traditional model involves the parties sharing their identities with each other and other intermediaries such as correspondence banks, credit companies, and even processing groups. The same intermediaries, whether they are trusted third parties to the transaction or otherwise, are privy to the details of the individuals involved in an exchange.

When describing privacy, in relation to identities the Bitcoin white paper refers to the ability to keep public keys anonymous in the context of participants outside of those who require knowledge of the transaction.

But looking it as a whole, rather than anonymity, it is privacy. It is about keeping details away from the public. This of course does not apply to those who were involved in the exchange and certainly not those who are required by law to monitor such exchanges. Those who are involved in an exchange have to perform the record-keeping of transactions and identities dependent on what regulations the service providers are working in and what the local jurisdiction requires them to store.

The realisation of this misconception lead to the creation of anonymous blockchain systems like Monaro and z-Cash but instead of using the term anonymous, they were dubbed privacy blockchain which was intended to mislead regulators who typically take a while before they catch up to new technology innovative methods.

In the recent past, some of the blockchains started using mixer services to achieve such anonymity which is being shut down by various jurisdictions. In other attempts, there was introduction of Segwit protocol on the bitcoin blockchain, which removes the digital signature out of the public storage in the block. Digital signatures associate with identities and when that is not publicly stored on blockchain, it allows for creating anonymous systems around it.

To summarise, any system which allows for anonymous money exchanges will always be a magnet for those looking to engage in illegal and criminal activities. This is why the Bitcoin protocol specifically mandates that blockchain integrates a digital signature when dealing with money. All digital signatures will require a system which will be used to create signatures which in turn, will require associated identities. If any system is built either by changing the protocol or by working around it, it will violate the legal requirements of money handling services in most countries where it operates and will be considered illegal.

A public blockchain defined by the Bitcoin whitepaper publishes transactions in cleartext on the ledger, which means that any information published as part of the transaction is available globally for anyone to read and use. This is a very different approach to privacy than what is traditionally done, especially when it comes to financial transactions. The whitepaper itself describes this concept as shown in the diagram below.

The traditional privacy model obfuscates everything regarding identity and transacting intermediaries and entities. None of this information is made public to protect sensitive data from malicious usage.

In the Bitcoin protocol’s privacy model, as shown in the bottom half of the diagram, identities are firewalled and decoupled from the transactional data. This means that all of this information is to be stored in private databases just like it is done today for full data sets, including transactional data. But here, the transaction data is made public. This change and attributes provide a new way of building private systems while keeping the advantages of public blockchain’s openness and transparency features.

The example also annotates the example of a comparison made between information that is kept private and public in the case of a credit card payment transaction and the case where BSV Blockchain is used for a payment transaction.

Privacy and identity are highly important considerations in the blockchain world. This topic will examine both core concepts and how they fit within the blockchain ecosystem.

We have already looked at the composition of a transaction. Now, let's dig a bit deeper.

Data structure of a transaction:

Data Structure of a BEEF formatted transaction:

The following image provides an example of a typical raw transaction (P2PKH transaction with two inputs and two outputs):

The colors help to differentiate every field present in the transaction. Input script is denoted as scriptSig, and output script is denoted as scriptPubKey (due to the nature of the input script being a signature and output being a script locking the funds to a public key).

Each field in the transaction is modularised i.e. you can build a raw transaction one by one by adding each of these fields in the right format and endianness. These transactions are usually built using well-defined libraries and functions available in various programming languages.

There will often be visualisation tools which will present the transaction details in a much more readable format; for example, below is the translated version of the input and output scripts for the raw transactions in discussion.

Once the transaction is constructed, it is submitted for timestamping. This can be done via an Overlay Service or directly to the node network. Currently, nodes provide an RPC endpoint (called bitcoind), which is made available for transactions to be submitted, but the ARC service provides an easy to use abstraction.

One of the most misunderstood aspects of blockchain is Identity. From the notion that possession of keys represents ownership to claims that Bitcoin allows anonymous value exchange, there has been many such assertions that has mislead not just the individuals but governments who are trying to regulate this technology. Let’s look at some of the concepts around this to analyse their validity and impact on designing systems to better understand how Identity and Privacy work in the world of Web3.

In the Account model every account is represented by an Identity. A common misconception is that the same applies to the UTXO model used in the Bitcoin protocol.

A UTXO is created when funds are locked to a Public Key infrastructure (PKI) key-pair. The logic was extended from legacy-based understanding that, since it stores funds, the key-pair becomes an identifier of its owner. This is not the case, as is illustrated in the example below.

For Payment transactions (any type of transactions which focus on using BSV as payment method)

The above examples depict scenarios where data and payment transactions are made in hypothetical entities and where identity resides in these flows. It is not possible for anyone to determine who the transactions and funds belong to on the blockchain, unless someone publicly declares that they own a certain key (presuming they have some form of proof of ownership). But that again, is the same as a merchant storing KYC information; the record-keeping of identity is done off-chain and never on the blockchain.

Taking the analogy in the traditional account model where you deposit money in a bank account; this becomes a loan to the bank for a certain rate of interest that the bank pays to you. The bank stores your KYC information and can conduct enquiries to determine whether you have obtained it by valid means. That means the bank validates that the money you deposit has been obtained using legally valid means. When you transact the bank actually does that for you. This is called the bank acting in lieu of their customer.

The mere possession of a key does not give ownership. In the traditional banking system, knowing the password for accessing a bank account doesn't mean that you own money. If someone without authorisation does this they are legally conducting theft. In the same way, Similarly, if someone uses a key-pair which is not legally owned by them, they are conducting theft involved in theft and this will be evidenced using the proof that the funds were acquired from and who owns them. In the same way that having a copy of a house key does not provide you with ownership of a house, a key does not provide you with ownership of bitcoin.

Digital signatures are used extensively in blockchain, however there is common misunderstanding on how they work. This subject is associated with how keys and their ownership work as discussed earlier. Electronic signatures are not just widely used in commerce and contracting but also the legal structure is quite clear when it comes to what is an electronic signature and how identity is associated with these signatures.

The following diagram shows the process of how digital signatures are used.

The signature that gets generated by the signer is generated based on the identity of the signer. Once that signing happens, identity is tied to the signature. The information that ties the signature is typically stored in a registry or local storage of the signature service provider.

A signature is generated by the signer based on the signer's identity. This ties the identity to the signature. The information is typically stored in the signature service provider's registry or local storage.

It is not necessary for a signature to reference the individual's first and last name but does need some mark which identifies it as resulting from the act of the party. For a digital signature algorithm to link the key to an individual and hence the act, there needs to be some way to register and control the signature key, otherwise it would not be possible to prove that the individual engaged in the act, and some other extrinsic evidence would need to be provided that proves the control of the key at the time the signature was reportedly made.

Introduction

The Network Access Rules is the set of rules regulating the relationship between the BSV Association and the nodes on BSV. It details their duties and obligations to the network and their relationship with the Association. The rules are grounded in the principles of the Bitcoin Protocol and the Bitcoin White Paper, ensuring that all nodes contribute to a lawful and honest network environment, providing transparency and guidance for network participants. Network activities in this instance include collecting, validating, or accepting a block, collating transactions into a block, attempting to find a proof-of-work for a block, or broadcasting a block.

Version: 1

Upload Date: 15/02/2024 Changelog:

• 27/02/2024: Minor v1 grammatical and formatting corrections and added FAQ

PART I - MASTER RULES

1. The Rules in overview

   1. The ‘Rules’ comprise a multilateral legal agreement between and among the Association and all Nodes.

   2. The Rules include the Master Rules (Part I), the General Rules (Part II), the Enforcement Rules (Part III), the Dispute Resolution Rules (Part IV), and the Interpretive Rules (Part V), but do not include the recitals in the Background to the Rules.

   3. The Rules supersede the Unilateral Contract as between and among the parties to the Rules in relation to its subject matter, without prejudice to any accrued rights and liabilities any party to the Rules may have under that earlier agreement.

2. Agreement to the Rules

   1. Each Node confirms and communicates its agreement to the Rules when it:

      • (a) conducts any Network Activity;

      • (b) uses the Node Software; or

      • (c) uses or takes any benefit of the Node Software Licence.

   2. In the Rules, the term ‘Relevant Activity’ means any and all of the activities in clause I.2.1.

   3. Any person who has not agreed and does not agree to the Rules should not undertake any Relevant Activity.

3. Network Activities and Block Reward

   1. Each time a Node conducts a Network Activity, such Node agrees that it will use best endeavours to undertake the following six steps to run the Network set out in the Bitcoin White Paper:

      • (a) new transactions are broadcast to all Nodes;

      • (b) each Node collects new transactions into a block;

      • (c) each Node works on finding a difficult proof-of-work for its block;

      • (d) when a Node finds a proof-of-work, it broadcasts the block to all Nodes;

      • (e) nodes accept the block only if all transactions in it are valid and not already spent; and

      • (f) 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.

   2. Each Node may compete to earn a ‘Block Reward’ by undertaking Network Activities subject to and in accordance with the Rules. This Block Reward may comprise: (i) transaction fees; and (ii) other block incentive fees (‘Block Subsidies’), subject to the Block Subsidies decreasing over time in accordance with the Bitcoin Protocol.

   3. No party to the Rules represents or guarantees that any person will earn any Block Rewards.

   4. Each Node acknowledges that, except as may be provided for expressly in the Rules, no fees, payments, or reimbursements are due or may become due to it, from the Association or any Affiliate of the Association regarding such Node’s performance of any of its obligations under the Rules or its conduct of any Relevant Activity.

4. Network access criteria

   1. Each Node severally represents and warrants to the Association and to each other Node (which representations will be deemed to be made upon entry to the Rules and repeated by each Node every time such Node carries on any Relevant Activity, as well as at all times that the Rules remain applicable to that Node) that:

      • (a) the Node’s conduct of any Relevant Activity is in accordance with the Bitcoin Protocol;

      • (b) if the Node is a legal entity, it is duly organised and validly existing under the laws of the jurisdiction of its organisation and incorporation and, if applicable under such laws, in good standing;

      • (c) the Node has the power and (in the case of an individual) full capacity to: (i) enter the Rules and any other documentation relating to the Rules; (ii) to perform its obligations under the Rules and any other documentation relating to the Rules; and (iii) it has taken all necessary action to authorise such entry and performance;

      • (d) all governmental and other consents, licences, authorisations, permits, contracts, and other approvals (if any) that are required to enable the Node to enter into the Rules and any other documentation relating to the Rules and perform its obligations under the same have been obtained by it and are in full force and effect, and all conditions of the same have been complied with;

      • (e) by the Node entering into the Rules, conducting any Relevant Activity, and performing its obligations or exercising any rights under the Rules, it will not violate any Applicable Laws, any provision of its constitutional documents, or any third-party rights binding on it or any of its Affiliates;

      • (f) without prejudice to the generality of clause I.4.1(e) above, by the Node entering into the Rules, conducting any Relevant Activity, and performing its obligations or exercising any rights under the Rules, it will not violate any Data Protection Laws;

      • (g) neither that Node nor any of its Affiliates is a Sanctions Restricted Person; and

      • (h) the Node’s obligations under the Rules constitute its legal, valid, and binding obligations in accordance with the Rules, enforceable in accordance with their terms subject to applicable bankruptcy, reorganisation, insolvency, moratorium, examinership, fraudulent conveyance laws, or any other similar laws affecting creditors’ rights generally and subject, as to enforceability, to equitable principles of general application (regardless of whether enforcement is sought in a proceeding in equity or at law).

   2. Each Node agrees that its rights under the Rules will be suspended if and for so long as any of its representations or warranties in clause I.4.1 are untrue.

5. Node responsibilities

   1. Each Node agrees that it will not, directly or indirectly, do or attempt to do any of the following:

      • (a) conduct any Relevant Activity otherwise than in accordance with the Rules;

      • (b) misuse, damage, overload, disrupt, or cause a significant adverse effect to the Network or the Network Database;

      • (c) use any Malicious Code, including any programmes or software that may, in the Association’s reasonable and good faith opinion, interfere adversely with the normal operation of the Network or the collection, storage, processing, or transmission of any data or transactions via the Network; or

      • (d) access any part of the Network without authorisation or otherwise than in accordance with the Rules.

   2. Each Node further agrees that it will always and at its own cost and without delay:

      • (a) take all lawful action as may reasonably be required to ensure the application of the Rules to it;

      • (b) comply in all respects with Applicable Laws in connection with the performance of its obligations under the Rules and its conduct of any Relevant Activity;

      • (c) without prejudice to that Node’s other obligations under the Rules: (i) follow and abide by the Bitcoin Protocol when conducting any Network Activities; and (ii) act honestly within the meaning of the Bitcoin White Paper;

      • (d) only carry out Network Activities using either: (i) a version of the Node Software that includes all released functionalities (unless the Association has expressly designated those functionalities as discretionary in writing); or (ii) other software of its own choosing so long as it abides by and is compatible with the Bitcoin Protocol and the Rules, and allows Nodes to receive informational messages broadcast by the Association via the Network (each a ‘Message’);

      • (e) comply with the applicable terms of any Node Software Licence if it is using the Node Software;

      • (f) maintain adequate systems, equipment, processes, and controls to allow it to receive and respond to any notices and system notifications from the Association, including Messages, and to perform its obligations under the Rules in an efficient and timely manner;

      • (g) notify the Association as soon as possible of any potential performance or vulnerability threat of significance to the Association, the Network, or Nodes generally; and

      • (h) use best endeavours not to introduce material into the Network or Network Database which: (i) is malicious; (ii) the control, ownership, possession, or distribution of is prohibited under Applicable Laws; (iii) is technologically harmful; or (iv) may reasonably result in significant cyber-risks or vulnerabilities to us, the Network, or Nodes generally.

6. Node acknowledgements

   1. Each Node acknowledges, agrees, and accepts that unless expressly stated elsewhere in the Rules:

      • (a) the Association is not under any obligation to Nodes or any other person to monitor and enforce compliance with the Rules (or any similar agreement the Association has with a third party), even though the Association may carry out such activities;

      • (b) nothing in the Rules is to be construed or interpreted as the Association taking or accepting any responsibility or liability for the roles, responsibilities, or obligations of any Node or third parties;

      • (c) the Association is not obligated to exercise (or to not exercise) any of its powers under the Rules, but if such powers are exercised, the Association undertakes to act with reasonable care and skill in the exercise of the relevant power(s); and

      • (d) the Association cannot and does not guarantee the Network’s reliability, integrity, or performance.

7. Nodes’ individual and collective obligations

   1. Unless otherwise expressly provided in the Rules and subject to clause I.7.2, the obligations of each Node under the Rules are independent of the obligations of each other Node, and the liability of each Node will be several and extend only to any loss or damage arising out of its own breach.

   2. A Node’s liability under the Rules will be joint and several together with any other Nodes or third parties which are, in the reasonable and good faith opinion of the Association, acting together with that Node pursuant to an agreement or understanding (whether formal or informal, but not including the Rules).

   3. Any party to the Rules may bring a separate action or actions against any Node under the Rules, or release any claim they have against any other Node, without affecting the liability of any other party to the Rules and irrespective of whether any other party is joined in any such action.

8. Liability

   1. In this clause I.8 references to liability include all present and future liabilities, actual or contingent, of every kind arising under or in connection with the Rules including liability in contract, tort (including negligence), misrepresentation, restitution, or otherwise.

   2. Nothing in the Rules limits any liability which cannot legally be limited, including liability for: (i) death or personal injury caused by negligence; and (ii) fraud or fraudulent misrepresentation.

   3. Subject to clause I.8.2:

      • (a) each Node irrevocably releases and forever discharges all other Nodes from all liability arising directly or indirectly from any Step taken by that Node and its Affiliates in good faith according to the express requirements of a Directive;

      • (b) the Association will have no liability to any Node bringing a claim or prospectively bringing a claim if that Node fails to notify the Association of such claim promptly or in any event no more than six months from the date when that Node was first aware, or ought reasonably to have become aware, of any of its alleged grounds to make a claim, or from the date of the event giving rise to the claim having first occurred (whichever is the earlier). Such notice must be in writing and provide sufficient details for the Association to understand and respond to the proposed claim;

      • (c) the Association will not be liable to any Node for any step taken reasonably and in good faith in performing (or purporting to perform) any obligation it may have under the Rules or in exercising (or purporting to exercise) any power or discretion it may have under the Rules; and

      • (d) the Association will not be liable for the following types of loss: (i) loss of profits; (ii) loss of sales or business; (iii) loss of agreements or contracts; (iv) loss of anticipated savings; (v) loss of use or corruption of software, data, or information; (vi) loss of or damage to goodwill; (vii) pure economic loss arising out of or in connection with the Rules; or (viii) indirect or consequential loss.

9. Suspension

   1. The Association may suspend the rights of, and any obligations owed by any party to, a Node (the ‘Suspended Node’) by notice where the Association determines reasonably and in good faith that:

      • (a) to do otherwise may be a violation of, be inconsistent with, or expose the Association or the Network to any liability under Applicable Laws;

      • (b) the Suspended Node has breached any of Part I of the Rules (Master Rules);

      • (c) the Suspended Node (being an individual) dies or, because of illness or incapacity (whether mental or physical), becomes incapable of managing its affairs or is detained under any mental health legislation; or

      • (d) the Suspended Node (being a company, corporation, other body corporate, organisation or association) has ceased to exist, is insolvent or unable to pay its debts as they become due, or there is a material risk to that Node’s creditworthiness or financial status.

10. Governing law

    1. The Rules and any dispute or claim arising out of or in connection with them or their subject matter, existence, negotiation, validity, termination, or enforceability (including any non-contractual disputes or claims) will be governed by and construed in accordance with the law of England and Wales

\

Background to the Rules

Part I - Master Rules

1. The Rules in overview

2. Agreement to the Rules

3. Network Activities and Block Reward

4. Network access criteria

5. Node responsibilities

6. Node acknowledgements

7. Nodes’ individual and collective obligations

8. Liability

9. Suspension

10. Governing law

Part II – General Rules

1. Affiliates

2. The relationship of the parties

3. Entire agreement

4. No implied terms

5. Changes to the Rules

6. Assignment

7. Indemnity

8. Tax

9. Intellectual property

10. Third-party rights

11. Rights and remedies

12. No waiver

13. Set-off

14. Notices

15. Severability

16. Language

Part III - Enforcement Rules

1. Directives

2. Nodes’ obligation to follow Directives

3. Enforcement Event

4. Direct Decision Event

5. Indirect Decision Event

6. Restrictions on Directives

7. Information obligations

Part IV - Dispute Resolution Rules

1. Arbitration

2. Binding nature

3. Changes

Part V - Interpretive Rules

1. Principles of interpretation

2. Glossary

Background to the Rules

• A. BSV Association (the ‘Association’ or ‘we’, ‘our’, or ‘us’) is a non-profit organisation based in Switzerland. Our goals are to support the operation of the Network and foster the growth of the Bitcoin Satoshi Vision (‘Bitcoin’, ‘Bitcoin SV’, or ‘BSV’) ecosystem. We aim to achieve this by protecting and supporting the vision of ‘Satoshi Nakamoto’ in the paper ‘Bitcoin: A Peer-to-Peer Electronic Cash System’ published on 31 October 2008 (the ‘Bitcoin White Paper’), ensuring the Bitcoin Protocol remains ‘set in stone’, offering educational resources, research, and information, as well as by establishing a regulation-friendly ecosystem that encourages honest behaviour, nurtures digital currency, and facilitates blockchain innovation.

• B. In the Bitcoin White Paper, the public was offered the opportunity to obtain up to 20,999,950 electronic coins in the aggregate if they abided by certain rules, including those set out in the Bitcoin White Paper (the ‘Unilateral Contract’).

• C. Participants in the Bitcoin SV ecosystem support adherence to the Bitcoin Protocol and the terms of the Unilateral Contract and seek to maintain the vision in the Bitcoin White Paper.

• D. While the Association provides stewardship of the Network, it is the responsibility of those persons who conduct Network Activities from time to time, whether individually or collectively (each a ‘Node’), to promote and maintain honest and lawful behaviour in line with the Bitcoin White Paper’s vision. ‘Network Activities’ means collecting, validating, or accepting a block, collecting transactions into a block, attempting to find a proof-of-work for a block, or broadcasting a block.

• E. To achieve the Bitcoin White Paper’s vision, a common framework with clear standards and practices for Nodes is essential. This framework, embodied in the Rules, enables legal recourse between Nodes if a Node has breached the Rules. The Rules also enable the Association to take legal and technical actions, such as sending informational messages alerting Nodes to breaches of the Rules, so as to support the ecosystem in counteracting unlawful and dishonest behaviour on the Network. Our goal is to exercise all of our rights, powers, and discretions under the Rules in a way that promotes the stability of the Bitcoin Protocol over time.

• F. We have therefore published the Rules, which build upon and supersede the Unilateral Contract, to offer the users of the Network increased legal certainty, confidence, and security and to protect the long-term growth and success of the Network. By conducting any Relevant Activities (including any Network Activities), a Node agrees to be bound by the Rules.

• G. We also offer licences for using the Node Software (the ‘Node Software Licence’), the full terms of which may be found here. The Association recognises the vital role of software, especially secure open-source types, in optimising the Network’s functionality and Node compliance with the Rules, and supports innovative software development by Nodes, both independently and in collaboration. If a Node uses the Node Software or takes advantage of the Node Software Licence, it has also agreed to be bound by the Rules.

Part V - Interpretive Rules

1. Principles of interpretation The following principles of interpretation apply to the Rules:

   • (a) references to parties are to the Association and Nodes, and not to any third parties;

   • (b) references to a person will include a natural person, corporate, or unincorporated body (whether or not such body has a separate legal personality);

   • (c) references to a company will include any company, corporation, or other body corporate, wherever and however incorporated or established;

   • (d) a reference to any of a Node’s obligations under the Rules will include an obligation not to procure, permit, or suffer that thing to be done;

   • (e) a reference to writing or written excludes fax but includes being recorded by any means and, includes email and messages in any human-readable format or representing words in any visible form sent through the Network;

   • (f) a reference to signing includes an electronic signature, but only where signed through a secure operating system or platform which, in the Association’s reasonable opinion: (i) allows the signature to be uniquely linked to the signatory and capable of identifying them; and (ii) provides a link to the signed data in such a way that any subsequent change in the data is detectable;

   • (g) any reference to a legal term for any action, remedy, method of judicial proceeding, legal document, legal status, court, official, or any legal concept or thing will, in respect of any jurisdiction other than England and Wales, be deemed to include a reference to that which most nearly approximates to the legal term in that jurisdiction which is equivalent to that in England and Wales;

   • (h) unless the context otherwise requires, words in the singular will include the plural, and words in the plural will include the singular;

   • (i) unless the context otherwise requires, the words ‘or’ and ‘and’ will be interpreted such that ‘A or B’ means ‘A or B or both,’ ‘either A or B’ means ‘A or B, but not both,’ and ‘A and B’ means ‘both A and B’; and

   • (j) any words following the terms including, include, in particular, for example, or any similar expression will be interpreted as illustrative and will not limit the sense of the words preceding those terms.

2. Glossary

The following definitions apply to the Rules:

PART II - GENERAL RULES

1. Affiliates

   1. Each Node agrees that it will use best endeavours to procure that each of its Affiliates will comply with the obligations and restrictions in the Rules as if they applied to that Affiliate in the same manner that they apply to that Node (with any necessary alterations made).

2. The relationship of the parties

   1. Nothing in the Rules is intended to or will be deemed to: (a) create any partnership, unincorporated association, or joint venture between any parties to the Rules; (b) cause any party to the Rules to become an agent for another party to the Rules (whether as a fiduciary or otherwise); or (c) authorise any party to the Rules to make or enter any commitments for or on behalf of another party to the Rules.

3. Entire agreement

   1. Without prejudice to any accrued rights under the Unilateral Contract:

      • (a) the Rules constitute the entire agreement and understanding between and among the parties with respect to their subject matter;

      • (b) each Node acknowledges and agrees that, in entering the Rules, it has not relied on and will have no remedy in respect of any oral or written representations, warranty, or other assurance or prior understandings (including in connection with any recitals in the Background to the Rules) except as expressly provided for or referred to in the Rules; and

      • (c) each Node agrees that it will have no claim against any other Node or the Association for innocent misrepresentation, negligent misrepresentation, or negligent misstatement based on any statement in the Rules.

4. No implied terms

   1. No terms are implied into the Rules: (a) by trade, custom, practice, or course of dealing; (b) by statute, to the fullest extent permitted by law (including the terms implied by Part II of the Supply of Goods and Services Act 1982); or (c) which restrict the Association’s exercise of powers under the Rules or otherwise.

5. Changes to the Rules

   1. The Association may change all or any of the terms in the Rules.

   2. The Association will notify Nodes of any changes to the Rules on the Website or using any of the other methods described in clause II.14 (a ‘Change Notice’). Each Node agrees to check the Website at reasonable intervals for any new Change Notice.

   3. By conducting any Relevant Activity following the publication of a Change Notice, each Node is deemed to have accepted and to be bound by any changes described therein (irrespective of whether the Node or its agents have read such Change Notice). If a Node does not agree, it will cease to conduct any Relevant Activity immediately.

   4. Save as set out in this clause II.5, no variation of the Rules will be effective unless issued by or on behalf of the Association.

6. Assignment

   1. The Association may at any time assign, mortgage, charge, subcontract, delegate, declare a trust over, or deal in any other manner with any or all of its rights and obligations under the Rules.

   2. Nodes are not entitled to assign, mortgage, charge, subcontract, delegate, declare a trust over, or deal in any other manner with any or all of their rights or obligations under the Rules, whether by operation of law or otherwise.

7. Indemnity

   1. In this clause II.7, a reference to the Association will include the Association, each Affiliate of the Association, and the Association’s employees, officers, contractors, subcontractors, and agents.

   2. Each Node agrees to indemnify the Association and to keep the Association always indemnified against all or any reasonable liabilities, costs, claims, damages, losses, or expenses (including any direct, indirect, or consequential losses, loss of profit, loss of reputation, and all interest, penalties and legal costs, calculated on a full indemnity basis), and all other professional costs or expenses arising out of or in connection with:

      • (a) such Node’s breach, negligent performance, or failure or delay in performance of the Rules;

      • (b) the enforcement of the Rules by the Association against that Node or its Affiliates; or

      • (c) any claim made against the Association by any other Node or a third party to the extent that such claim arises out of or in connection with the indemnifying Node’s breach or negligent performance, or failure or delay in performance, of the Rules.

8. Tax

   1. Any payment required by the Rules will be made without a tax deduction unless required by law (in which case, the receiving party will be entitled to receive such amounts as will ensure that the net receipt, after tax, is the same as it would have been had no deduction been made).

9. Intellectual property

   1. Subject to any rights expressly granted under the Node Software Licence, the Association reserves all of its rights, title, and interest in and to the Node Software, including all Intellectual Property Rights.

10. Third-party rights

    1. Except as may be expressly provided elsewhere in the Rules, a person who is neither a party to the Rules nor any party’s successor or assignee will have no rights under the Contracts (Rights of Third Parties) Act 1999 or otherwise to enforce any term of the Rules.

    2. Without prejudice to the Association’s rights to vary the Rules in clause II.5, any rights the Association may have to terminate or rescind the Rules or agree to any variation, waiver, or settlement in connection with them are not subject to the consent of any third party even if it extinguishes or alters any entitlement that such third party may have to enforce any term of the Rules.

11. Rights and remedies

    1. The rights and remedies provided under the Rules are cumulative and are in addition to, and not exclusive of, any rights and remedies each party to the Rules may have in law or equity.

12. No waiver

    1. Any failure or delay by any Node or by the Association to insist upon strict performance of the Rules or to exercise or enforce any rights or remedies or any provision under the Rules will not constitute a waiver thereof unless that party has agreed to the waiver and expressly stated it to be such in writing, signed by it or on its behalf.

13. Set-off

    1. The Association maysetoff any amount that any Node owes it against any amount the Association owes to that Node under the Rules or otherwise, whether such debt is owed now or at any time in the future, whether it is liquidated or not and whether it is actual or contingent. If the liabilities set off are expressed in different currencies or cryptocurrencies, the Association may convert either liability at a reasonable market rate of exchange determined by the Association for the purpose of the set-off. However, the Association is not obliged to exercise its rights under this clause II.13.

    2. Each Node will pay any amounts due under the Rules in full without any set-off, counterclaim, deduction, or withholding (other than, subject to clause II.8.1, any deduction or withholding of tax as required by law).

14. Notices

    1. Any notice or communication in respect of the Rules, including one containing a Directive, may be given in writing in any manner described below only and, subject to clause III.2.2, will be deemed effective at the time indicated:

       To any Node:

       • (a) effective immediately: if delivered by hand to any address associated with a Node’s or any of its Affiliates’ Relevant Activities, including any registered office or premises or data centres owned, occupied, operated by, or otherwise associated with that Node or any of its Affiliates;

       • (b) effective immediately: if sent by electronic messaging system, by email or by messages or notifications through any Network-related software or other distributed ledger system, including communication by means of airdrop or transaction data transmission, in programming or in natural language, to any address or wallet controlled by or associated with that Node or any of its Affiliates (or which the Association reasonably determines in good faith is so controlled or associated) or in respect of which that Node or any of its Affiliates has an interest at the time of transmission;

       • (c) effective at 9:00 am UTC on the seventh Business Day after posting: if sent by pre-paid registered post to any registered office or premises or data centres owned, used, occupied or operated by that Node or any of its Affiliates;

       • (d) effective immediately: if published on the Website or the Repository.

       To the Association:

       • (e) effective at 9:00am UTC on the next Business Day following delivery: if delivered by hand to the Association’s registered office on a Business Day or if sent by email to legal@bsvblockchain.org or to such address as the Association specifies for that purpose on the Website; and

       • (f) effective at 9:00am UTC on the seventh Business Day after posting: if sent by pre-paid registered post, including airmail, to: BSV Association, Grafenauweg 6, 6300 Zug, Switzerland.

    2. All notices under the Rules will, unless sent electronically, be signed by or on behalf of the sender. Notices which are sent electronically (other than pursuant to II.14.1(d)) will be digitally authenticated by the sender.

    3. All notices provided under the Rules will be in English or accompanied by a certified translation.

    4. This clause II.14 does not apply to the service on the Association of any notice of legal proceedings or other documents in any legal action, arbitration, or other form of dispute resolution process.

15. Severability

    1. In the event any clause of the Rules is for any reason found invalid or unenforceable in any respect, such invalidity or unenforceability will not affect the validity of any remaining clauses, which will remain in full force and effect as if the invalid or unenforceable clause was never a part of the Rules.

16. Language

    1. The Rules are made in the English language. Where there is any conflict in meaning between the English language version of the Rules or any translation in any other language, the English language version will prevail, and the translation will be for reference only.

PART III - ENFORCEMENT RULES

1. Directives

   1. Subject to clause III.6, the Association may in its absolute discretion issue a direction to a Node requiring it to take a Step or Steps (a ‘Directive’) where there is:

      • (a) an Enforcement Event;

      • (b) a Direct Decision Event; or

      • (c) an Indirect Decision Event.

   2. In the Rules, the term ‘Directive Event’ refers to any of the events in clause III.1.1. These Directive Events are defined below.

2. Nodes’ obligation to follow Directives

   1. Subject to clauses III.6 and III.2.2, each Node will promptly comply with the requirements of any Directive applicable to it following receipt of notice of the Directive and in any event no later than any time for compliance which is specified in the notice of the Directive.

   2. Any Directive will take effect immediately upon notice to a Node or Nodes unless otherwise expressly stated in the notice of the Directive.

3. Enforcement Event

   1. An ‘Enforcement Event’ occurs in respect of any one or more Nodes when the Association reasonably determines in good faith that one or both of the following has occurred:

      1. (a) a breach by the relevant Node(s) of any of Part I of the Rules (Master Rules), clause II.1 (Affiliates), clause II.7 (Indemnity), or clause III.2 of these Rules; or

      2. (b) any representation or warranty in the Rules given by the relevant Node(s) is false or misleading when made, repeated, or deemed to have been made or repeated.

4. Direct Decision Event

   1. A ‘Direct Decision Event’ occurs when the Association receives a Decision that the Association reasonably determines in good faith is a Direct Decision.

   2. A ‘Direct Decision’ is a Decision that:

      • (a) has the force of law, has been recognised, or is enforceable in England and Wales or Switzerland;

      • (b) has as one of its subjects the Association or its Affiliates or their respective property or activities; and

      • (c) relates to or concerns the Network, the Network Database, the conduct of any Relevant Activity by any Node(s), or the ownership, possession, transfer, content, or control of BSV.

5. Indirect Decision Event

   1. An ‘Indirect Decision Event’ occurs when the Association receives a Decision which the Association reasonably determines in good faith is an Indirect Decision.

   2. An ‘Indirect Decision’ is a Decision that:

      • (a) has the force of law, has been recognised, or is enforceable in England and Wales or Switzerland;

      • (b) is not a Decision which has as one of its subjects the Association or its Affiliates or their respective property or activities; and

      • (c) relates to or concerns the Network, the Network Database, the conduct of any Relevant Activity by any Node(s), or the ownership, possession, transfer, content, or control of BSV.

6. Restrictions on Directives

   1. The Association may not issue a Directive where there has been no Directive Event.

   2. A Directive may only require a Node or Nodes to do any or all of the following steps (each a ‘Step’):

      • (a) freeze specified coins in unspent transaction outputs;

      • (b) blacklist or whitelist specific IP addresses as peer connections in the Node Software;

      • (c) reassign frozen coins; or

      • (d) invalidate specified blocks.

   3. A Node is only required to take an action that the Association has reasonably determined in good faith is necessary to achieve one or more of the following purposes (each a ‘Purpose’):

1. Information obligations

   1. Each Node agrees that it will notify the Association promptly of any circumstances which are reasonably likely to give rise to a Directive Event.

   2. Each Node agrees that, on demand by the Association, it will promptly provide the Association with any information the Association may reasonably request in connection with the Rules or any Enforcement Event.

   3. Nothing in this clause III.7 requires a Node to disclose information where the disclosure by that Node would breach Applicable Laws.

PART IV - DISPUTE RESOLUTION RULES

1. Arbitration

   1. Any dispute, controversy, or claim arising out of, or in relation to, the Rules, including regarding the existence, validity, invalidity, breach, or termination thereof, will be resolved by arbitration in accordance with the Swiss Rules of International Arbitration of the Swiss Arbitration Centre in force on the date on which the Notice of Arbitration is submitted in accordance with those rules (the ‘Swiss Rules’). In particular:

      1. (a) the number of arbitrators will be one or three;

      2. (b) when designating or appointing an arbitrator, the parties, the arbitrators, and the Arbitration Court of the Swiss Arbitration Centre, in view of securing the appointment of a qualified, independent and impartial arbitrator, are invited to consider the opportunity, as appropriate, of designating or appointing arbitrators of the P.R.I.M.E. Finance Panel of Experts and any of the specialised panels that P.R.I.M.E. Finance may form to deal with particular categories of blockchain or digital assets-related cases;

      3. (c) the seat of the arbitration will be Zug, Switzerland;

      4. (d) the arbitration proceedings will be conducted in English;

      5. (e) the law applicable to the arbitration agreement will be the law of England and Wales; and

      6. (f) the rules on expedited proceedings as set out in Article 42 of the Swiss Rules will apply where the amount in dispute does not exceed the amount specified for their application in the Swiss Rules or where the parties to the arbitration agree in writing that those rules do not apply.

   2. Binding nature

      1. The arbitration agreement in clause IV.1 is binding on each Node, irrespective of when that Node first undertakes or undertook a Relevant Activity.

   3. Changes

      1. This Part IV (Dispute Resolution Rules) (including the arbitration agreement in clause IV.1) is subject to change in accordance with clause II.5 of the Rules.

      2. Any changes to this Part IV (Dispute Resolution Rules) will not result in the arbitration agreement in clause IV.1 ceasing to have binding effect.

Alongside the release of the new Network Access Rules, this FAQ aims to help nodes and other interested parties better understand the new rules and what they mean for them clearly and concisely.

Disclaimer

The content of these documents is provided for informational purposes only and is not intended to modify or supersede the contractual rights or obligations of any party to the Network Access Rules. Parties are encouraged to carefully review the Network Access Rules to verify the accuracy of the information presented here. It is assumed that, where necessary, parties will seek guidance from their legal counsel and any other advisors they consider necessary.

Any statements here do not purport and should not be considered to be a guide to, advice on, or explanation of all relevant issues or considerations relating to the contractual relationship established by the NAR. The BSV Association assumes no responsibility for any use to which the BSV network is put by any miner or other third party.

\

The following does not constitute legal advice. All relevant issues cannot be considered. The assumption is that, where appropriate, miners will consult with their legal advisers and any other adviser they deem appropriate.

Disclaimer

The content of this document is provided for informational purposes only and is not intended to modify or supersede the contractual rights or obligations of any party to the Network Access Rules. Parties are encouraged to carefully review the Network Access Rules to verify the accuracy of the information presented here. It is assumed that, where necessary, parties will seek guidance from their legal counsel and any other advisors they consider necessary.

Any statements here do not purport and should not be considered to be a guide to, advice on, or explanation of all relevant issues or considerations relating to the contractual relationship established by the NAR. The BSV Association assumes no responsibility for any use to which the BSV network is put by any miner or other third party.

Timestamp Server

BSV uses a distributed timestamp server to create a public record of transactions. This is achieved by hashing transactions into an ongoing chain, forming a record that is computationally impractical to alter. Each timestamp includes the previous timestamp in its hash, forming a chain of blocks, or a “blockchain.”

Proof of Work

To maintain this chain, BSV uses a proof-of-work system. Nodes, which are essentially powerful computers, compete to solve complex mathematical problems. Solving these problems involves finding a hash value that meets certain criteria (e.g., begins with a specific number of zero bits). The first node to find a valid solution broadcasts its block to the network.

Block Creation and Verification

When a node finds a valid proof-of-work, it broadcasts the block to all other nodes. These nodes verify the block to ensure all transactions are valid and not already spent. Once verified, the new block is added to the chain, and the nodes begin working on the next block, using the hash of the previous block as a reference.

Chain of Proof

The longest chain of blocks represents the sequence of events witnessed by the network. This chain is considered the correct one because it has the most proof-of-work effort invested in it. If nodes control the majority of CPU power and act honestly, they will create the longest chain and outpace any attackers trying to alter past transactions.

Immutability and Security

Once a block is added to the blockchain, altering it would require redoing the proof-of-work for that block and all subsequent blocks, which is computationally infeasible if the network’s honest nodes control the majority of the hash power. This ensures the immutability and security of the transaction history.

Decentralized Consensus

The network reaches consensus without a central authority. Each node operates independently, validating transactions and blocks. Nodes follow the longest chain rule, where they consider the longest valid chain as the true record of transactions.

This system ensures that transactions are timestamped and recorded in a secure, decentralized manner, allowing for an immutable and verifiable history of events on the BSV blockchain. The reliance on proof-of-work and the decentralized nature of the network are key factors that enable BSV to function effectively as a timestamp server.

What is Web3?

• Shift from pure computer networks to semantic networks

• Individual devices maintin their own state (could be cloud, local, or hybrid)

• Direct e2e communication (P2P

• micro-transactions for every interaction

• Every device has its own filters/language which makes them part of a semantic network of other devices that filter/understand the same transaction types

• UTXO model: every transaction is atomic, so TXs become native metadata to each interaction

• Every device is unique yet can still be part of a network or community

• communication is agnostic to the physical medium the transaction is communicated over

• Syncing is optional because every Satoshi lives as a unique double-spend protected commodity token regardless of what it's transfer is capturing

Ticket Distributor example

1. Distributor creates tranches of tickets and combines the hash of each ticket with pubKey from a public-private EC-keypair.

• This can be done by converting the key and the hash to big numbers, combining them (either by hashing, adding, multiplying, subtracting, or xoring) and multiplying the result by the generator point of the curve, G.

• Each tranche only need to be 1 transaction and each output is associated with a ticket.

• Tickets are unique

• Tranches provide a way for distribution attributes to be included such as early-bird pricing

1. The distributor distributes the tickets to sellers by spending the ticket outputs to outputs each of the sellers control. They also give the sellers the ticket hashes, the basic ticket information, and the Merkle paths which the sellers can use to perform an SPV check. They could aslo include the ticket hashes in a separate output or in a pattern such as ticket with the ticket hash immediately following it: vout0 = combined, vout1 = ticket hash.

   1. This could represent a transaction type. A version hash could also be included in the version field of the transaction to denote it being part of a particular event or tranche.

2. The sellers sell the tickets repeating the same process that was used to give them tickets with each sale.

3. Event attendees can then spend their ticket at the gate using the same process

In the example, the ticket distributor and the sellers are both overlay services because they're providing a service and tracking sales data (in this way, a merchant can be considered an overlay service). However, they communicate with each other and the event attendees in the same way: P2P.

It's the fact they all understand the ticket transaction that makes them part of the same semantic overlay network for that specific event. The sellers and the ticket distributor can consider themselves part of a more generalized event ticket overlay.

The benefits of doing things this way:

• It maintains the properties of the blockchain by leveraging them through the use of Satoshis. No additional high-level overview tracking needs to be done. Once the TXs have been distributed, they can either get spent at the gate of the event, or they can be refunded back to the seller who can then either resell them or refund them back to the ticket distributor.

• The process can be started by an event group by having the event group provide the necessary Satoshis for each of the tickets along with a payment (This can be the generating TX).

• In addition, SIGHASH flags can be used to allow the tickets to be resold within the same transaction by allowing inputs and outputs to be adjusted:

  • For example, SIGHASH_NONE/ANYONE_CAN_PAY where the seller signs their input but none of the outputs so the event attendee can change the output and sign the change.

  • It doesn't matter who spends the ticket to attend the concert as long as they have the Merkle path from the seller for the gate to check

Analogy: polymorphism

• Nodes understand shapes

• high-level overlays (like the ticket distributor and sellers) understand shapes such as circles or squares: The event in the example can be associated with the shape of a circle.

  • The nodes only see the circles and square as shapes

• Each event can be analogized as a colour; e.g., the event in the example above can be associated with the colour red.

• So:

  • The nodes, ticket distributor, sellers, and event attendees all understand shapes

  • The ticket distributor, sellers, and event attendees also understand circles

  • The ticket distributor, sellers, and event attendees also understand red circles

  • The ticket distributor and sellers understand blue circles (another event) but the event attendee that bought tickets for the red circle event and not the blue circle event, does not understand blue circles.

  • The event company working the gate understands red circles, but not blue circles, so if an attendee for the blue circle event tried to attend the red circle event, they would not be able to get in because the gate company would not understand the output (via SPV and validation checks)

• This is how polymorphism works: a general type (base transactions) are understood by everyone, but more specific types are only understood by certain classes or entities, yet fundamentally, every entity is interoperable because the general type they understand is the same, any specificity is overlayed on to the general type making it more specific.

Disclaimer

The content of this document is provided for informational purposes only and is not intended to modify or supersede the contractual rights or obligations of any party to the Network Access Rules. Parties are encouraged to carefully review the Network Access Rules to verify the accuracy of the information presented here. It is assumed that, where necessary, parties will seek guidance from their legal counsel and any other advisors they consider necessary.

Any statements here do not purport and should not be considered to be a guide to, advice on, or explanation of all relevant issues or considerations relating to the contractual relationship established by the NAR. The BSV Association assumes no responsibility for any use to which the BSV network is put by any miner or other third party.

Disclaimer

The content of this document is provided for informational purposes only and is not intended to modify or supersede the contractual rights or obligations of any party to the Network Access Rules. Parties are encouraged to carefully review the Network Access Rules to verify the accuracy of the information presented here. It is assumed that, where necessary, parties will seek guidance from their legal counsel and any other advisors they consider necessary.

Any statements here do not purport and should not be considered to be a guide to, advice on, or explanation of all relevant issues or considerations relating to the contractual relationship established by the NAR. The BSV Association assumes no responsibility for any use to which the BSV network is put by any miner or other third party.

\

OP_NOP1-OP_NOP10 were originally set aside to be used when HASH and other security functions become insecure due to improvements in computing.

False is zero or negative zero (using any number of bytes) or an empty array, and True is anything else.

Opcodes that will be activated in the Chronicle Release are indicated by an asterisk (e.g. OP_VER*).

Constants

When talking about scripts, these value-pushing words are usually omitted.

Flow control

Stack

Data Manipulation

Bitwise logic

Arithmetic

BitcoinScript supports arithmetic on bignum values A bignum is a byte sequence that represents a numeric value. The length of the byte sequence must be less than or equal to 750,000 bytes. Byte sequences larger than 750,000 bytes are valid in Bitcoin however current rules dictate that they are not recognised as a valid numeric value.

Note that while some operations require parameters to be valid numeric values, they may produce byte sequences which are not valid numeric values (for example, OP_MUL may produce a byte sequence which is too large to validly represent a numeric value).

Cryptography