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

Was this helpful?

Edit on GitHub
Export as PDF
  1. Network Access Rules
  2. FAQs

Miners

Are the Network Access Rules a contract?

The Network Access Rules (NAR) within the BSV blockchain are foundational to its operation, serving as a critical legal and operational framework. These rules are not just guidelines but form a multilateral contract between and among the BSV Association (BSVA) and each node participating in the network. Acceptance of the contract is implicit, established by the very act of a node joining and engaging in relevant activities (including network activities) within the BSV ecosystem.

When a node decides to partake in the BSV network, it inherently agrees to abide by the NAR. This agreement is not formalised through a traditional contract signing; rather, it is a contract that is agreed, confirmed, and automatically in force once a node commences network activities. These network activities include essential functions such as collecting, validating, and accepting blocks, compiling transactions into blocks, attempting to find a proof-of-work for a block, or broadcasting a block to the wider network. Further, if a node uses the node software or takes advantage of the node software license then the contract will also take effect.

This contractual relationship, designed for and compatible with blockchain technology, is pivotal for the BSV network. It ensures that every node, by participating in the network, consents to and is bound by a set of predefined rules and standards. These rules are designed to maintain network integrity, security, and functionality. They confirm the legal framework within which nodes operate, providing clarity and consistency in how the network functions.

The NAR encompass various aspects of network operation, including compliance with laws, adherence to technical standards, and the execution of network activities as per the original Bitcoin Protocol. This comprehensive approach ensures that every participant in the network contributes to a stable, secure, and legally compliant blockchain environment. By agreeing to the NAR, nodes are committing to uphold the principles and protocols that define the BSV network, first laid out in the original Bitcoin White Paper.

What role do mining nodes play in the enforcement of the Network Access Rules?

Mining nodes play a crucial role in the enforcement of the Network Access Rules (NAR). While the decision-making process for NAR is the responsibility of the BSV Association (BSVA), which acts as the steward of the BSV network and is the sole entity authorised to amend the NAR, miners participate in the enforcement of these rules.

Mining nodes enforce the NAR by implementing directives received through the Alert System, which is managed by the BSVA. These directives may only be issued by the BSVA in specific situations as specified in the NAR. Miners' compliance and execution of these directives contribute significantly to maintaining network integrity and help ensure that only honest and lawful transactions are recorded on the BSV blockchain.

Miners are also empowered under NAR to bring contractual claims against other miners who have breached NAR. NAR even contemplates the possibility of miners bringing claims against the BSVA to enforce its provisions.

How do the Network Access Rules impact the day-to-day operations of miners on the BSV network?

The Network Access Rules (NAR) do not alter the day-to-day operations of miners on the BSV network. Miners are already obligated to adhere to these standards and protocols as part of their routine activities. These obligations primarily include following the six steps outlined in section 5 of the Bitcoin White Paper to operate the network under the original Bitcoin Protocol and ensuring compliance with relevant laws. Additionally, miners must respond to various directives, which may encompass security updates and alerts that can impact their mining operations.

In essence, the NAR serve as a framework to enforce these pre-existing behaviours and requirements. Their purpose is to safeguard the network's integrity for the benefit of honest miners and users with a view to ensuring that all participants continue to operate in accordance with understood and binding rules, established legal standards, and best practices.

How do miners stay compliant with the Network Access Rules?

Miners should always run software – whether that be the node software or other software – which allows for receiving alert messages through the Alert System, to facilitate information sharing for security threats, and promptly implement any security directives to ensure both compliance and security of the network.

How does the Alert System affect mining rewards and block propagation for miners?

The Alert System may issue directives that could impact block validation or propagation (e.g., freezing certain unspent transaction outputs (UTXOs)). Compliance with these alerts may therefore temporarily affect mining rewards. However, this procedure is designed to ensure long-term network integrity and value.

For example, a message may be published that directs nodes to invalidate a specific block that includes a transaction that transfers funds which have a freeze order against them since such funds have been identified to be proceeds of crime. In this case the miner who broadcasts that block will lose the block reward from that block and another proof of work solution will need to be found by nodes that do not attempt to transfer coins under the applicable freeze order.

Are there any incentives for miners related to enforcing the Network Access Rules?

Miners are incentivised to comply with the Network Access Rules (NAR) to maintain their mining rewards and network participation as well as to have clarity at being covered by the NAR. The NAR are designed such that they do not impede or adversely impact honest nodes in the long run. They incentivise nodes to have awareness about any current freeze orders and to be as well connected to other nodes as possible so that they will never inadvertently build a block with a double spend in it. There also exists the natural incentive for nodes to ensure the BSV Blockchain is compliant under existing regulatory requirements, to ensure its long term growth and stability.

Are there any consequences for miners who do not follow the Network Access Rules?

Consequences may include blocks being invalidated, losing connections as an eligible peer, or other enforcement actions for non-compliance (all within the confines of the restrictions on the BSV Association (BSVA)’s powers set out in the Network Access Rules (NAR)).

Having blocks a miner produced deemed invalid means the money that was spent to produce the block is wasted since no block reward will be received. This will ensure that miners want to follow the directives issued through the Alert System.

What is the function of the BSV Association?

The BSV Association (BSVA) serves as the principal steward of the BSV network, entrusted with multiple critical functions. Here’s an overview of its key functions:

  • Stewardship: The BSVA’s primary function is to steward the BSV network. This involves communicating essential information and updates to miners and other network participants, primarily through the Alert System. This system is crucial for disseminating important security updates, alerts, and guidance to maintain the network's integrity and efficiency.

  • Educational Support and Software Development: The BSVA also focuses on providing educational resources and supporting software development initiatives. This function is vital in equipping the BSV community with the necessary knowledge and tools to optimise network participation and foster technological innovation within the blockchain space.

  • Enforcement of the Network Access Rules (NAR): As a party to the NAR, the BSVA has well-defined duties and obligations towards network miners and nodes, as set out in NAR. The association ensures that these rules are adhered to, and it can be held accountable for any breaches or overreaching actions. This enforcement is key to maintaining a fair, secure, and orderly network.

  • Compliance with Legal Directives: A significant part of the BSVA’s role involves enforcing legal directives, particularly regarding the freezing or reassignment of unspent transaction outputs (UTXOs). Utilising the Alert System, the BSVA facilitates network compliance with relevant court orders, thereby aligning the BSV network with relevant legal standards and regulatory requirements.

In essence, the BSVA's role is to ensure that the BSV network operates within a secure, legal, and efficient framework, balancing the needs of network participants with the overarching goal of maintaining a stable and trustworthy blockchain environment.

What are the implications for miners operating in jurisdictions with strict regulatory requirements related to digital assets?

Miners in strict regulatory environments must ensure that their operations, including compliance with the Network Access Rules (NAR), align with all applicable local laws.

How can miners ensure the security of their mining infrastructure in the context of the Alert System?

The Alert System adds to the security of all core infrastructure of the network by identifying and alerting all honest participants of malicious behaviour. By listening and acting upon validly signed alerts, honest nodes contribute to the overall security of the BSV network.

Miners, for example, who repeatedly violate the NAR, or who use their infrastructure for processing sanctioned frozen transactions or double spends, may find themselves in breach of applicable laws concerning the prohibited transfer of money.

Who are the alert key holders?

Five parties are designated by the BSV Association (BSVA), who hold mobile devices that are used to sign alert messages only under the circumstances specified in the NAR and within the boundaries specified therein. These parties are responsible to be available on an ad hoc basis for real time responses, and are ultimately responsible for approving the sending of alert messages to the network. A message is signed when it has three out of the five keyholders sign.

The goal is to have a diverse group of key holders who can collectively ensure the security and integrity of the alert system. For security their keys will be rotated on a scheduled basis.

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.

\

PreviousFAQsNextProfessionals

Last updated 12 months ago

Was this helpful?