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
  • Private/Public Key Generation
  • Message Signing and Verification
  • Signature Format

Was this helpful?

Edit on GitHub
Export as PDF
  1. BSV Academy
  2. Digital Signatures
  3. BSV and Digital Signatures

ECDSA (secp256k1) for BSV Transaction

As we now have a high-level conceptual understanding of BSV transactions, we will now look at the specifics of key generation, signing and verification in BSV. It is critical to note that the inner workings of the Elliptic Curve Digital Signing Algorithm(secp256k1) remain the same. However, there are some subtle differences to be aware of.

Private/Public Key Generation

Recall that the first step of the Digital Signing protocol is generating the public and private keys. The equation below gives the relationship between private and public keys, and the same applies to BSV.

Public key=Private key∗Base PointPublic \ key = Private \ key * Base \ PointPublic key=Private key∗Base Point ; ---------------------(1)

  • The private key is an integer

  • The base point is element on the curve to which when group operation is applied repeatedly. It generates all the other elements of the cyclic group. In this case, the elements are points on the curve

  • A public key is one such point on curve and has an xxx and yyy co-ordinate

While we explain the generation of private-public keys from a consumer/end-user perspective, when building enterprise applications, organizations may choose to implement this functionality by themselves depending on their use case.

GIF

Users have wallets; wallets generate "Private Keys".

A private key is a 256-bit random big number. Generally, a private key is not used in the raw format but encoded into a standardized format known as WIF (Wallet Import Format).

Once a private key is generated, the public key is derived using the above equation (1). A public key is a point on the curve, and it is either 33 bytes or 65 bytes. If it's 33 bytes, the public key is compressed and 65 bytes if uncompressed. In practice, a public key is used in a compressed form where the first byte indicates if the y-coordinate is odd or even, and the remaining 32 bytes are the value of the x-coordinate. In the uncompressed format, the first byte indicates that the public key is uncompressed, the next 32 bytes are the value of x-coordinate, and the remaining 32 bytes represent y-coordinate.

Furthermore, wallets adopt two best practices, which we need to be aware of to understand private/public keys in BSV completely. These practices focus on security, privacy, and usability.

  1. Security and Privacy - Wallets ought to generate a new private-public key pair for each new transaction. If the same key pair is used for every transaction, there are two drawbacks. Firstly, exposure of one private key exposes all transactions all transactions which can be unlocked with that key. Secondly, if the same public key is used for all the transactions, then the ownership of funds becomes easily traceable using analytics and monitoring tools. Therefore, to provide users privacy and security against specific attacks, wallets incorporated generating a new key pair for every transaction.

  2. Usability - While the above implementation provides security and privacy; it also creates some issues with usability. As each new use of a public key means there will be a new private key, users will need to back up the wallet after each transaction in which they receive funds. This usability issue precipitated the improvement known as "Hierarchical Deterministic key" (HD keys). With this approach, all other key pairs are derived in a hierarchy, with the parent being the seed key. This solution keeps the privacy and security aspects intact and requires the user to only have to back up the seed key. Furthermore, to enhance usability of backing up the seed key (which is a very long random string of digits), the key pair hierarchy is derived from a bag of words, which is easier to remember and manage than the long hexadecimal string.

Message Signing and Verification

It is critical to understand that digital signatures in BSV are always encapsulated within a transaction. Expressly, the application of digital signatures, i.e., signature and verification, are instructed by the script in transactions.

There is a field within the data structure of the transaction inputs which is "Txin-script / scriptSig," and similarly, the transaction outputs have a field "Txout-script / scriptPubKey." These fields are used for providing unlocking and locking scripts for funds, respectively.

Though there are no protocol restrictions, currently, most BSV transactions use a standardized template. The standardized template governs the value for "Txin-script / scriptSig" and "Txout-script / scriptPubKey." For a beginner level of know-how, the below-generalized understanding would suffice.

  • "Txin-script / scriptSig" contains the signature and corresponding public key

  • "Txout-script / scriptPubKey" includes a public key or "public key hash". Public key hash is the public key double-hashed by SHA-256 first, then RIPEMD-160 secondly.

  • BSV transactions are committed using the Distinguished Encoding Rules [DER, sighash] format, which we shall discuss later

  • The signature verification is done by combining and comparing the unlocking script and locking script and evaluating whether that yields a true or false result. This has already been covered under Script evaluation.

Note - The above understanding provides an abstraction of how a transaction works in BSV. There may be a requirement to verify the signature against a public key for enterprise applications before the transaction reaches the nodes. The general practice used by applications is to not share a public key but rather a BSV address; which is a public key double hashed as Address = RIPEMD-160(SHA-256(Kpub)(K_{pub)}(Kpub)​) and this output is then encoded as a base58 string of 20 bytes.

Signature Format

Recall from the ECDSA chapter that signature consists of pair of integers (r,s)(r, s)(r,s). BSV transactions use a format [DER, SIGHASH]. We shall now elaborate on the DER and SIGHASH parts.

  1. DER - Distinguished Encoding Rules (DER) specify digital signatures in binary format and standardized by OpenSSL. In essence it is a way to serialize the signatures for transmission or storage. The format for DER is [header, length, rheader, rlength, r, sheader, slength, s]

    1. header - A static value 0x30

    2. length - The total length of the rest of the signature (i.e., rheader, rlength, r, sheader, slength, s)

    3. rheader - A static value 0x20

    4. rlength - Length of r, after encoding as a big-endian integer

    5. r - r encoded as a big-endian integer

    6. sheader - A static value 0x20

    7. slength - Length of s, after encoding as a big-endian integer

    8. s - s encoded as a big-endian integer

    Note - big-endian is an encoding format that provides a more human readable array of binary bytes when serializing and storing numbers bigger than 256, i.e., 2^8.\

  2. SIGHASH - The purpose of this flag is to provide flexibility in constructing transactions by specifying which part of the transaction is expected to be signed. SIGHASH is analogous to an enumeration and is set to either of six values provided below. Also, while we generally say transaction inputs or output to be signed, technically, the corresponding unlocking script should have the signature / public key.

    Recall transactions can have multiple inputs and outputs.

    1. SIGHASH_ALL - sign all the inputs and output of the transaction; value = 0x01

    2. SIGHASH_NONE - sign all inputs and no outputs; value = 0x02

    3. SIGHASH_SINGLE - sign all the inputs and outputs with same index; value = 0x03

    4. SIGHASH_ALL | ANYONECANPAY - sign its own input, and all outputs; value = 0x81.

    5. SIGHASH_NONE | ANYONECANPAY - sign its own input, and no outputs; value = 0x82

    6. SIGHASH_SINGLE | ANYONECANPAY - sign its own input and outputs with the same index; value = 0x83

    Generally, most transactions use SIGHASH_ALL; for beginner level, it is sufficient to know the same.

    Note - Before signing the transaction input or output, it is hashed using SHA-256. - Currently, all the BSV transactions require an additional SIGHASH flag which is SIGHASH_FORKID, and it adds the value 0x40 to SIGHASH value. So value 0x01 for SIGHASH_ALL becomes 0x41 and so on.

\

PreviousBSV TransactionNextSummary

Last updated 2 months ago

Was this helpful?