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
  • Token and its distribution
  • Network Consensus
  • Energy Investment

Was this helpful?

Edit on GitHub
Export as PDF
  1. Protocol
  2. BSV Blockchain

Economic Model of Governance

Bitcoin (protocol) is an economic system and its governance incentivises its usage

PreviousCapabilitiesNextDigital Asset Recovery

Last updated 11 months ago

Was this helpful?

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.

Nodes governed by the POW system, the public nature of the ledger and the decoupling of identity are the three factors that make a blockchain valuable. These features enable a non-trusted intermediary in a payment system for the first time.

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.

Incentive model in Bitcoin Protocol