LogoLogo
LogoLogo
  • Intro
    • Welcome
    • The Benefits of BSV Blockchain
    • What Can I Do?
    • Overview of GitHub repositories
    • Quick Start
  • Protocol
    • Introduction
    • BSV Blockchain
      • Blocks
      • Transactions
      • Proof of Work
      • Capabilities
      • Economic Model of Governance
      • Digital Asset Recovery
    • Network Policies
      • High-Level Architecture
      • Mining
      • Standard and Local Policies
      • Consensus Rules
      • Local Policies
    • Node Operations
      • Node Software
      • Bitcoin Server Network (BSN)
      • ChainTracker
      • Transaction Validation
      • UTXO Storage
      • Mempool
      • Block Assembler
      • Block Validation
      • Mining Software
      • Pruning transactions
      • Responsibilities of a Node
    • SPV Wallets, Overlays and SPV Processes
      • Simplified Payment Verification (SPV)
      • Instant Payments
      • Integrity Checks
      • SPV Wallets & Overlays
    • Transaction Lifecycle
      • Transaction Inputs and Outputs
      • Script
      • Transaction Flow
      • Constructing a transaction
      • Sequence Number and Time Locking
      • Transaction Templates
      • Transaction Processing
      • Opcodes used in Script
    • Privacy
      • Keys and Identity
      • Private vs Anonymous
      • Digital Signatures
      • Privacy on the Public Blockchain
  • Network Access Rules
    • Rules
      • Table of Contents
      • Background to the Rules
      • PART I - MASTER RULES
      • PART II - GENERAL RULES
      • PART III - ENFORCEMENT RULES
      • PART IV - DISPUTE RESOLUTION RULES
      • PART V - INTERPRETIVE RULES
    • FAQs
      • Miners
      • Professionals
      • Users
  • Important Concepts
    • High Level
      • Web3
      • Timestamping
      • SPV
      • UTXO vs Account Based
      • Linked Keys
      • Smart Contracts
    • Details
      • Hash Functions
      • Merkle Trees
      • Sighash Flags
      • Script
      • SPV
        • Deep Dive
        • Payments Flow
        • Data Models
        • Broadcasting
  • Network Topology
    • Mandala Upgrade
    • Nodes
      • SV Node
        • Architecture
        • System Requirements
        • Installation
          • SV Node
            • Configuration
            • AWS Volumes Setup
            • DDOS Mitigation
            • Docker
            • Genesis Settings
            • GetMiningCandidate
            • GKE
            • Network Environments
              • Regtest
              • STN
              • Testnet
        • Alert System
          • Alert Messages
          • Running the Alert System
            • Startup Script
          • Webhooks
        • RPC Interface
          • RPC Methods
        • Frequently Asked Questions
          • Blocks
          • Initial Block Download
          • Transactions
          • Log File Warnings
          • Safe Mode
          • Bug Bounty
        • Chronicle Release
      • Teranode
    • Overlay Services
      • Overlay Example
    • SPV Wallet
      • Quickstart
      • Key Concepts
      • AWS Deployment
        • Installation
        • Manage & Maintain
        • Update
        • Delete
      • Components
        • SPV Wallet Server
        • Storage
        • Web Admin
        • Block Headers Service
        • Web App & API
      • Who is it for?
      • Functionality & Roadmap
      • Contribute
      • Developers Guide
        • SPV Wallet
          • Authentication
          • Configuration
          • Notification
        • Go Client
          • Authentication
        • JS Client
          • Authentication
        • Admin
        • Keygen
        • Block Headers Service
          • Authentication
          • Configuration
      • Additional Components
  • paymail
    • Overview
    • BRFC Specifications
      • Specification Documents
      • BRFC ID Assignment
    • Service Discovery
      • Host Discovery
      • Capability Discovery
    • Public Key Infrastructure
    • Payment Addressing
      • Basic Address Resolution
      • Sender Validation
      • Receiver Approvals
      • PayTo Protocol Prefix
    • Verify Public Key Owner
    • Recommendations
  • Guides
    • Local Blockchain Stack
      • Mockchain Stack
    • Business Use Cases
      • Creating a Tranche of Event Tickets
    • SDKs
      • Concepts
        • BEEF
        • Fees
        • SPV
        • Transactions
        • Op Codes
        • Script Templates
        • Signatures
        • Verification
      • TypeScript
        • Node, CommonJS
        • React
        • Low Level
          • Verification
          • ECDH
          • Numbers & Points
          • Signatures
          • 42
          • ECDSA
          • Hmacs
          • Keys
          • Scripts
        • Examples
          • Creating a Simple Transaction
          • Verifying a BEEF Structure
          • Creating Transactions with Inputs, Outputs and Templates
          • Creating the R-puzzle Script Template
          • Message Encryption and Decryption
          • Message Signing
          • Building a Custom Transaction Broadcast Client
          • Verifying Spends with Script Intrepreter
          • BIP32 Key Derivation with HD Wallets
          • Using Type 42 Key Derivation for Bitcoin Wallet Management
          • Creating a Custom Transaction Fee Model
          • Building a Pulse Block Headers Client
          • Using ECIES Encryption
      • Go
        • Examples
          • Simple Tx
          • Keys
          • Encryption
          • Broadcasting
          • Inscribing
          • Data Markers
          • Linked Keys
          • ECIES
          • Fees
          • HD Keys
          • Headers
          • Secure Messages
          • Merkle Path Verification
      • Python
        • Examples
          • Simple Tx
          • Verifying BEEF
          • Complex Tx
          • Script Templates
          • Encryption
          • Message Signing
          • Building A Custom Broadcaster
          • HD Wallets
          • Linked Keys
          • Fees
          • Merkle Path Verification
          • ECIES
  • BSV Academy
    • Getting Started
    • BSV Basics: Protocol and Design
      • Introduction
        • Bit-Coin
      • The BSV Ledger
        • The Ledger
        • Triple Entry Accounting
        • Example
      • Coins and Transactions
        • Coins
        • Transactions
        • Transaction Fees
      • Theory
      • Conclusion
    • BSV Enterprise
      • Introduction
      • About BSV Blockchain
        • Introduction
        • Safe, Instant Transactions at a Predictably Low Cost
          • Reliably Low Fees
          • Comparison to Legacy Transaction Systems
          • Payment Channels
        • Scalability to Accommodate Global Demand
          • Big Blocks Show Big Potential
        • A Plan for Regulatory Acceptance
          • Ready-made Compliance
          • The Open BSV License
        • Protocol Stability
          • Building Foundations on a Bedrock of Stone
      • Technical Details
        • The Network
          • The Small World Network
          • Robust In Its Unstructured Simplicity
        • The Bitcoin SV Node Client
          • Teranode - The Future of BSV
        • The Protocol - Simple, Robust and Unbounded
          • What is the BSV Protocol?
        • Proof of Work
          • The Algorithm
          • Efficiency of Proof of Work
        • Privacy and Identity
        • Permissions and Privacy
      • Resources and Tools
        • The Technical Standards Comittee
          • TSC Principles
          • Standard Development Process
          • Status of Current and In-progress Standards
        • The Working Blockchain
          • Pruning to Create a Working Blockchain
          • Building a Working Blockchain from a List of Block Headers
          • A World View Backed by Proof of Work
    • Hash Functions
      • What are Hash Functions?
        • The Differences Between Hashing and Encryption
        • The Three Important Properties of Hash Functions
        • The Hash Functions Found in BSV
      • Base58 and Base58Check
        • What is Base58 and Why Does Bitcoin use it?
        • What is Base58 and How Does BSV use it?
      • SHA256
        • BSV Transactions and SHA-256
        • BSV Blocks and SHA-256
        • Proof-of-Work and HASH-256
      • Walkthrough Implementation of SHA-256 in Golang
        • Overview of SHA-256
        • SHA-256 Input and Processing
        • SHA-256 Compression
        • SHA-256 Final Value Construction and Output
      • RIPEMD-160
        • BSV Addresses & WIFs
      • Walkthrough Implementation of RIPEMD-160 in Golang
        • Overview of RIPEMD-160
        • RIPEMD-160 Input and Processing
        • RIPEMD-160 Compression
        • RIPEMD-160 Final Value Construction and Output
      • Doubla Hashing and BSV's Security
        • Why is Double Hashing Used in BSV
        • Hash Functions and BSV's Security Model
    • Merkle Trees
      • The Merkle Tree
        • What is a Merkle Tree?
        • Why use a Merkle Tree?
        • Merkle Trees in Action
      • Merkles Trees in BSV
        • The Data Elements
        • Transaction Merkle Trees
        • Transaction Merkle Trees in Action
      • Merkle Trees and the Block Header
        • What is the Block Header
        • The Hash Puzzle
        • Proof-of-Work in Action
      • Merkle trees and Verifying Proof of Work
        • Broadcasting the Block
        • The Coinbase Transaction
        • Data Integrity of the Block
        • Saving Disk Space
      • Standarised Merkle Proof
        • What is a Merkle Proof?
        • The BSV Unified Merkle Path (BUMP) Standard
        • Simple and Composite Proofs
      • Merkle Trees and Simplified Payment Verification
        • SPV
        • Offline Payments
    • Digital Signatures
      • What are Digital Signatures
        • Background
        • Introduction
        • Digital Signatures Protocol
        • Properties of Digital Signatures
      • ECDSA Prerequisites
        • Disclaimer
        • Modular Arithmetic
        • Groups, Rings and Finite Fields
        • Discrete Logarithm Problem
        • Elliptic Curve Cryptography (ECC)
        • Discrete Logarithm Problem with Elliptic Curves
      • ECDSA
        • Introduction
        • ECDSA
        • Further Discussion
      • BSV and Digital Signatures
        • Introduction
        • BSV Transaction
        • ECDSA (secp256k1) for BSV Transaction
        • Summary
        • Signed Messages
        • Miner Identification and Digital Signatures
    • BSV Theory
      • Abstract
        • Peer-to-Peer Cash
        • Digital Signatures and Trusted Third Parties
        • Peer-to-Peer Network
        • Timechain and Proof-of-Work
        • CPU Power
        • Cooperation in the Network
        • Network Structure
        • Messaging Between Nodes
      • Introduction
        • Commerce on the Internet
        • Non Reversible Transactions
        • Privacy in Commerce
        • The Paradigm of Fraud Acceptance
        • What is Needed...
        • Protecting Sellers From Fraud
        • Proposed Solution
        • Security and Honesty
      • Transactions
        • Electronic Coins
        • Spending a Coin
        • Payee Verification
        • Existing Solutions
        • First Seen Rule
        • Broadcasting Transactions
        • Achieving Consensus
        • Proof of Acceptance
      • Timestamp Server
        • Timestamped Hashes
        • A Chain of Timestamped Hashes
      • Proof of Work
        • Hashcash
        • Scanning Random Space
        • Nonce
        • Immutable Work
        • Chain Effort
        • One CPU, One Vote
        • The Majority Decision
        • The Honest Chain
        • Attacking the Longest Chain
        • Controlling the Block Discovery Rate
      • Network
        • Running the Network
        • The Longest Chain
        • Simultaneous Blocks
        • Breaking the Tie
        • Missed Messages
      • Incentive
        • The Coinbase Transaction
        • Coin Distribution
        • Mining Analogy
        • Transaction Fees
        • The End of Inflation
        • Encouraging Honesty
        • The Attacker's Dilemma
      • Reclaiming Disk Space
        • Spent Transactions
        • The Merkle Tree
        • Compacting Blocks
        • Block Headers
      • Simplified Payment Verification
        • Full Network Nodes
        • Merkle Branches
        • Transaction Acceptance
        • Verification During Attack Situations
        • Maintaining an Attack
        • Invalid Block Relay System
        • Businesses Running Nodes
      • Combining and Splitting Value
        • Dynamically Sized Coins
        • Inputs and Outputs
        • A Typical Example
        • Fan Out
      • Privacy
        • Traditional Models
        • Privacy in Bitcoin
        • Public Records
        • Stock Exchange Comparison
        • Key Re-Use
        • Privacy - Assessment 2
        • Linking Inputs
        • Linking the Owner
      • Calculations
        • Attacking the Chain
        • Things the Attacker Cannot Achieve
        • The Only Thing an Attacker Can Achieve
        • The Binomial Random Walk
        • The Gambler's Ruin
        • Exponential Odds
        • Waiting For Confirmation
        • Attack Via Proof of Work
        • Vanishing Probabilities
      • Conclusion
        • Conclusion Explained
    • Introduction to Bitcoin Script
      • Chapter 1: About Bitcoin Script
        • 01 - Introduction
        • 02 - FORTH: A Precursor to Bitcoin Script
        • 03 - From FORTH to Bitcoin Script
        • 04 - Bitcoin's Transaction Protocol
        • 05 - Transaction Breakdown
        • 06 - nLockTime
        • 07 - The Script Evaluator
      • Chapter 2: Basic Script Syntax
        • 01 - Introduction
        • 02 - Rules Around Data and Scripting Grammar
        • 03 - The Stacks
      • Chapter 3: The Opcodes
        • 01 - Introduction
        • 02 - Constant Value and PUSHDATA Opcodes
        • 03 - IF Loops
        • 04 - OP_NOP, OP_VERIFY and its Derivatives
        • 05 - OP_RETURN
        • 06 - Stack Operations
        • 07 - Data transformation
        • 08 - Stack Data Queries
        • 09 - Bitwise transformations and Arithmetic
        • 10 - Cryptographic Functions
        • 11 - Disabled and Removed Opcodes
      • Chapter 4: Simple Scripts
        • 01 - Introduction
        • 01 - Pay to Public Key (P2PK)
        • 02 - Pay to Hash Puzzle
        • 03 - Pay to Public Key Hash (P2PKH)
        • 04 - Pay to MultiSig (P2MS)
        • 05 - Pay to MultiSignature Hash (P2MSH)
        • 06 - R-Puzzles
      • Chapter 5: OP_PUSH_TX
        • 01 - Turing Machines
        • 02 - Elliptic Curve Signatures in Bitcoin
        • 03 - OP_PUSH_TX
        • 04 - Signing and Checking the Pre-Image
        • 05 - nVersion
        • 06 - hashPrevouts
        • 07 - hashSequence
        • 08 - Outpoint
        • 09 - scriptLen and scriptPubKey
        • 10 - value
        • 11 - nSequence
        • 12 - hashOutputs
        • 13 - nLocktime
        • 14 - SIGHASH flags
      • Chapter 6: Conclusion
        • Conclusion
    • BSV Infrastructure
      • The Instructions
        • The Whitepaper
        • Steps to Run the Network
        • Step 1
        • Step 2
        • Step 3
        • Step 4
        • Step 5
        • Step 6
      • Rules and their Enforcement
        • Introduction
        • Consensus Rules
        • Block Consensus Rules
        • Transaction Consensus Rules
        • Script Language Rules
        • Standard Local Policies
      • Transactions, Payment Channels and Mempools
      • Block Assembly
      • The Small World Network
        • The Decentralisation of Power
        • Incentive Driven Behaviour
        • Lightspeed Propagation of Transactions
        • Ensuring Rapid Receipt and Propagation of New Blocks
        • Hardware Developments to Meet User Demand
        • Novel Service Delivery Methods
        • MinerID
      • Conclusion
  • Research and Development
    • BRCs
    • Technical Standards
  • Support & Contribution
    • Join Our Discord
    • GitHub
Powered by GitBook
On this page
  • Genesis Block Rule
  • Block Size Rule
  • Longest Chain Rule
  • Block Subsidy Rule
  • Difficulty Adjustment
  • Network consensus (also known as Nakamoto consensus)
  • First Seen rule
  • Transaction Consensus Rules

Was this helpful?

Edit on GitHub
Export as PDF
  1. Protocol
  2. Network Policies

Consensus Rules

The rules that define the protocol used for the blockchain

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.

It is possible to generate a point on an elliptic curve without directly deriving it from a private key. Such points can be generated mathematically or chosen from predefined points on the curve. However, these points are not associated with a private key in the cryptographic sense and thus cannot be used for typical cryptographic operations like signing or encryption/decryption.

Generating a Point on an Elliptic Curve

To generate a point on an elliptic curve, you can select an x-coordinate and then solve for the corresponding y-coordinate using the elliptic curve equation. For a curve defined by the equation:

y^2 = x^3 + ax + b

you can choose an x-coordinate and solve for y. This approach involves the following steps:

- 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).

Explanation

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.

Note

  • Quadratic Residue: The value x^3 + ax + b must be a quadratic residue in the field for a valid y to exist.

  • Security Considerations: The generated point is mathematically valid on the curve, but it isn’t associated with a private key. Such points can’t be used for operations requiring a private-public key pair.

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.

In the first 284 days of the launch of the Bitcoin blockchain network, there should be 144 blocks a day for a total of 41,000 blocks mined. That is 2 million bitcoin. Instead, only 1.25 million were mined at that point.

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.

Another aspect to look at is the 100 block rule for coinbase output. 100 blocks is the minimum number of blocks that a node has to wait before spending a coinbase transaction. Therefore after finding a valid block a node has an economic incentive to secure the network for 100 blocks. Therefore the window of nodes that can operate at the same time is 100. Because at any time max 100 nodes have economic incentives to maintain and secure the 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.

PreviousStandard and Local PoliciesNextLocal Policies

Last updated 10 months ago

Was this helpful?