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
  • What is PKI?
  • Digital Certificate
  • Certificate Authority
  • Registration Authority
  • Certificate Store
  • The Problems With PKI
  • What are HMACs?
  • The Problem With HMAC's
  • BSV's Approach to Security Using Hash Functions and Blockchain

Was this helpful?

Edit on GitHub
Export as PDF
  1. BSV Academy
  2. Hash Functions
  3. Doubla Hashing and BSV's Security

Hash Functions and BSV's Security Model

PreviousWhy is Double Hashing Used in BSVNextMerkle Trees

Last updated 2 months ago

Was this helpful?

To understand the role hash functions play in BSV's security, it's important to understand the overall approach to security BSV takes first. Although BSV uses the same primitives as current Public Key Infrastructure (PKI), it employs them in a much more granular and effective way. In all current information systems in use today, whenever any type of information is transferred, it’s sent from one account to another, and its most often fully end-to-end encrypted. By using UTXOs, BSV firewalls identity from network activity.

What is PKI?

Public Key Infrastructure or PKI is the set of elements and practices used to secure network communications. It's used to secure everything from email and web communication to bank transfers, digitally signing software, encryption, and smart card authentication.

To secure communication between two network participants, PKI uses certificates issued by a trusted 3rd party that form the basis of asynchronous end-to-end encryption between two participants.

PKI has 4 main elements: digital certificates, a certificate authority, a registration authority, and a certificate store.

Digital Certificate

Digital certificates work like passports. They're a form of electronic identification for websites and organizations. Two parties can be sure of each other's identities when they're both able to provide a trusted digital certificate to each other saying who they are.

For local area networks (LANs) or internal networks, internal digital certificates can be created locally. For commercial wide area network infrastructure like public websites, a digital certificate is obtained via a trusted 3rd party issuer called a Certificate Authority.

Certificate Authority

Certificate authorities are the arbiters of PKI systems. It's their job to authenticate the digital identities of the system participants.

Similar to a federal government issuing a passport, Certificate Authorities vet the system participants who are applying to get a trusted certificate. If the participant passes the Certificate Authority's vetting process, they're issued a trusted certificate, and the other participants in the system will communicate with the newly trusted entity based on the fact they were issued a trusted certificate by the Certificate Authority.

Registration Authority

Registration Authorities are actually a sub-part of Certificate Authorities. They interact with network participants and instruct Certificate Authorities to issue certificates. The purpose of Registration Authorities is to help make the PKI system more efficient. Instead of a single Certificate Authority handling all requests directly, participants interact with strategically distributed Registration Authorities.

Certificate Store

Certificate Stores are central repositories that hold all the certificate history and information related to the PKI system including issued certificates and private encryption keys. An example is Google Wallet.

The Problems With PKI

You may have noticed there are a couple of major security problems with PKI systems:

  1. If an attacker gains control of the Certificate Authority, they then gain the ability to infiltrate all network participants' systems because they can issue themselves a trusted certificate and none of the network participants would be able to tell they're actually communicating with an attacker.

  2. Storing all sensitive information in a single location creates a big incentive to attack or try to infiltrate said location because a single attack can gain the attackers access to all the private keys on the network.

However, there is one other security hole in PKI systems you may not have considered. Since all network communication is encrypted, if an attacker is able to convince a participant within the network to open a secure communication channel with them, the attacker is then able to send malware to and steal data from that participant and any others they're able to gain access to using the participant's trusted certificate because network administrators can't tell what's happening by looking at network traffic -- they have no idea what's being passed between two participants on the network.

This type of attack is called shovelling in the shell and it's a common attack vector used for many common cyber- crimes today like ransomware attacks or data exfiltration.

What are HMACs?

An HMAC (keyed-hash message authentication code or hash-based message authentication code) is a type of message authentication code (MAC) that uses a good hash function and a secret key. As with any message digest or MAC, it can be used to verify the authenticity and integrity of a message.

HMACs provide message authentication and integrity using a symmetric shared secret rather than asymmetric digital signatures. Instead of PKI, HMACs delegate the exchange of the shared secret to the communicating parties prior to messages being sent.

Any good hash function can be used for an HMAC. For example, if SHA-256 was used, the message would be an HMAC-SHA-256 message.

An HMAC doesn't encrypt the message. Rather, it's sent along with the message which can be encrypted or not, but its authenticity and integrity will be computable using the HMAC as long as the receiving party has the shared secret.

The Problem With HMAC's

HMACs have one major problem which is the communication of the shared secret between the two parties. If an attacker were to discover or intercept the shared secret, they can setup a man-in-the-middle-attack and, as with PKI, deploy a ransomware payload or exfiltrate sensitive information.

BSV's Approach to Security Using Hash Functions and Blockchain

BSV solves all the problems with PKI and HMACs by doing away with certificate authorities altogether, and making communications public.

BSV is a Write-Once-Read-Many (WORM) system. It's also an immutable time stamp service. As a result, once a transaction on the BSV blockchain has been widely distributed, its authenticity is no longer at risk. The first-seen-rule for transactions ensures the first transaction that spends a particular UTXO seen on the network is the accepted transaction.

Section 10. Privacy of the Bitcoin white paper describes BSV's new privacy model: "The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were."

Instead of having to rely on accounts, UTXOs allow for the encapsulation of each informational event – down to the packet. Rather than each individual using accounts which hold the entirety of each respective communication history like a Facebook or Google account, BSV allows each ‘post’, ‘like’, ‘email’, etc. to be an atomic event unto itself which is publicly recorded, yet occluded. Each UTXO is a record of ownership between individuals, but those individuals are only linked to the transactional event pseudonymously. This means illegal and nefarious actions are publicly time-stamped and traceable, but individual identity and activity remains private.

This also means that with BSV, it’s no longer necessary to communicate through an intermediary server or application which stewards each account-based ecosystem or network. With BSV's UTXO model, individuals can communicate directly – from “IP to IP”. Instead of sending an email to Google or Microsoft servers to be routed to its intended recipient which is expensive, and makes Google and Microsoft prime targets for data exfiltration, email can be sent directly from one individual’s email client to another’s.

Instead of the account-based model which requires a central authority to manage network activity and looks at events as occurring after a connection between the relevant parties has been made, BSV's UTXO model allows the identities of the relevant parties to be packaged into the event itself. This change in perspective creates the necessary pressures to cause the formation of a densely connected small-world network of nodes, which in turn, allows blocks sizes to grow and transaction fees to decrease.

It’s this scalability of the network – driven by the economic incentives and UTXO basis – that makes the BSV network so secure and efficient. Like the metaphorical cables of a suspension bridge, hash functions, Merkle trees, digital signatures, UTXOs, economic incentives, and the small-world emergent network formation all work in unison to make the BSV network the most secure and efficient system design in operation today.

For example, in 2011, DigiNotar, one of the largest certificate authorities in existence at the time, was hacked, and its root certificate key was compromised. This meant the entirety of all TLS/SSL encryption used by Microsoft, Google, and any other websites using a certificate issued by DigiNotar were also compromised. who was the victim of a Man-In-The-Middle attack on Google servers which allowed the attacker to create a relay connection between users and Google – meaning they could see all internet traffic being sent to and from Google servers. It was such a serious breach that DigiNotar was nationalized by the Dutch government (where it resided), and dissolved within a month. Bitcoin solves the “crunchy shell” model of certificate authorities like DigiNotar.

The problem was first publicly reported by a user in Iran