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
  • Satoshis Are Property
  • Diffie-Hellman Key Exchange and the Discrete Logarithm Problem (DLP)
  • Digital Signature Algorithm
  • Elliptic Curve Diffie-Hellman (ECDH) and the Elliptic Curve Digital Signature Algorithm (ECDSA)
  • What is a BSV Address?
  • What is a WIF?
  • Generating a Bitcoin ECDSA Public-Private Keypair in GoLang
  • How to Create a BSV Address in Golang
  • How to Create a Bitcoin WIF in GoLang:

Was this helpful?

Edit on GitHub
Export as PDF
  1. BSV Academy
  2. Hash Functions
  3. RIPEMD-160

BSV Addresses & WIFs

PreviousRIPEMD-160NextWalkthrough Implementation of RIPEMD-160 in Golang

Last updated 4 months ago

Was this helpful?

Satoshis Are Property

When a transaction is added to the ledger, it acts as a timestamped record of a change of ownership with satoshis (and whatever else is included in the transaction) being the property exchanged. Unlike account-based systems like a bank account where money is added and subtracted to and from the account with each transaction, satoshis aren’t actually ‘sent’ and ‘received' in UTXOs. In much the same way the ownership of gold is transferred without physically moving the gold, the ownership change of satoshis is tagged in UTXOs, and the event itself recorded in transactions. However, it’s important to note that BSV is not digital gold.

Since the BSV ledger is public, the ownership history of all 2,100,000,000,000,000 satoshis can be traced back to their issuance in 2009 by following the chain of digital signatures that link each UTXO and transaction in their history. This means Bitcoin doesn’t have accounts, so identity can be pseudonymously tied to each UTXO allowing macro-level activity to be visible while simultaneously providing individual privacy. It also means there’s a lot more flexibility in how transactions are conducted than account-based systems because a transaction doesn’t need to be submitted by an account holder; it can be submitted by anyone. However, identity is still a fundamental part of communication and UTXOs are still traceable and identity is still attributable when required.

All electronic communications are based on two concepts: using some kind of shared secret or signal so parties know they're talking to the correct people, and attributing identity to documents or messages so parties can attest to their ownership. The two most common methods used to make these two concepts a reality are the Diffie-Hellman key exchange algorithm and digital signatures.

Diffie-Hellman Key Exchange and the Discrete Logarithm Problem (DLP)

Much of the modern world is based on the concept of using a secure secret as a 'seed' value to encrypt communications: symmetric end-to-end (E2E) encryption. There are two problems with this approach:

  1. If everything is encrypted, how can attackers be stopped if they gain access to a system -- since system administrators can't tell good network traffic from bad because everything is encrypted.

  2. How do the communicating parties share the secret seed securely.

We explore how BSV addresses the first problem without using encryption in Chapter 7, but the answer to the second problem was found before the internet began, called the Diffie-Hellman key exchange, and it's based on the idea of using asymmetric, public-private, key-pairs to generate a symmetric shared secret, securely.

Published in 1976 by Ralph Merkle, and named after Whitfield Diffie and Martin Hellman, the Diffie-Hellman key exchange method is the earliest publicly known protocol for exchanging asymmetric keypairs. To this day, Diffie-Hellman is used extensively in everything involving end-to-end encryption, and even in the exchange of physical keys via written notes in some instances.

Digital Signature Algorithm

There's one big problem with the Diffie-Hellman key exchange algorithm: a nefarious actor could intercept the public keys during the exchange, posing as either Alice or Bob, and pass their own public key back. This is called a "man-in-the-middle" attack. Digital signatures are a solution to man-in-the-middle attacks.

A digital signature is a lot like a physical signature; it acts as to associate an individual identity to a document. The advantage digital signatures have over physical signatures is they're much easier to verify. Using a digital signature with at least one of the public key exchange messages in Diffie-Hellman can ensure the key is coming from who it's supposed to be coming from. The most popular digital signature algorithm -- used as the US government standard -- is the aptly named DSA.

  • Computing the signature:

  • Verifying the signature:

Elliptic Curve Diffie-Hellman (ECDH) and the Elliptic Curve Digital Signature Algorithm (ECDSA)

ECDH and ECDSA use pretty much the same process as standard Diffie-Hellman and DSA; again, the major difference being multiplication is used instead of exponentiation. For example, say Alice and Bob have decided to upgrade their system from standard Diffie-Hellman and DSA using a 3,072 bit key-size to ECDH and ECDSA, and they want to maintain the same level of security they currently enjoy:

  • Standard Diffie-Hellman:

  • ECDHA:

  • Standard DSA signature verification:

  • ECDSA signature verification:

Although BSV's UTXO model takes a different approach than full end-to-end encryption of all communications, it's still fundamentally based on the two ideas of a shared secret and digital signatures.

What is a BSV Address?

A BSV address is the RIPEMD-160 hash of the SHA-256 hash of the compressed x-coordinate of the public key of a public-private ECDSA key-pair prepended with a version byte and encoded in Base58Check… which sounds a lot more complicated than it actually is.

In P2PKH transactions, BSV addresses are the message digests or the “Public-Key-Hash" the satoshis are “Paid-to”.

What is a WIF?

A WIF (Wallet Import Format) key is similar to a Bitcoin address since they both use the Base58Check encoding; however, instead of using the compressed x-coordinate of the public key, the serialised ‘d' value of a private key is used, and WIFs don't use the HASH-160 of the key value.

Generating a Bitcoin ECDSA Public-Private Keypair in GoLang

package main 

import ( 
      "fmt" 
      "github.com/libsv/go-bk/bec" 
      "github.com/libsv/go-bt/v2/bscript" 
) 

func main() { 

      privKey, _ := bec.NewPrivateKey(bec.S256()) 

      pubKey := privKey.PubKey() 

} 

How to Create a BSV Address in Golang

Once a public-private ECDSA keypair has been generated, deriving a BSV address from the public key is easy:

package main 

import ( 
      "fmt" 
      "github.com/libsv/go-bk/bec" 
      "github.com/libsv/go-bk/crypto" 
      "github.com/libsv/go-bt/v2/bscript" 
)   

func main() { 

      privKey, _ := bec.NewPrivateKey(bec.S256()) 

      pubKey := privKey.PubKey().SerialiseUncompressed() 

      pubKey = crypto.Sha256(pubKey) 

      pubKey = crypto.Ripemd160(pubKey)   

      version := make([]byte, 0)       

      version = append(verison, 0x00) // 0x4d for testnet   

      pubKey = append(version, pubKey...)  

      address := bscript.Base58EncodeMissingChecksum(pubKey)   

      fmt.Printf("Address: %s\n", address) 
  
} 

1. Get the compressed x-coordinate of the public key:

pKey := pubKey.SerialiseCompressed() 

2. Hash the compressed x-coordinate of the public key with SHA-256:

pKey := crypto.Sha256(pKeyV) 

3. Hash the result of step 2 with RIPEMD-160:

pubKey = crypto.Ripemd160(pubKey) 

4. Create a new byte array and prepend with either 1 or ‘M' or 'N’ for mainnet or testnet, respectively:

version := make([]byte, 0) 

version = append(version, 0x00) // 0x4d for testnet 

5. Append the result of step 3 to the result of step 4:

pubKey = append(version, pubKey...) 

6. Generate and append a checksum to the result of step 5, and then encode the byte array in Base58:

address := bscript.Base58EncodeMissingChecksum(pubKey) 

7. Print result to standard out:

fmt.Printf("Address: %s\n", address) 

Activity – Generate a Bitcoin Address from a compressed public key

03baead150be4db1c985d1eac82e5370daad723bba35c859463970a0a1b5d39002

How to Create a Bitcoin WIF in GoLang:

package main 

import ( 
      "fmt" 
      "github.com/libsv/go-bk/base58" 
      "github.com/libsv/go-bk/bec" 
      "github.com/libsv/go-bk/crypto" 
)   

func main() { 

      privKey, _ := bec.NewPrivateKey(bec.S256()) 
  
      pKey := privKey.Serialise() 
  
      version := make([]byte, 0) //0xef for testnet 
  
      version = append(version, 0x80)   

      pKey = append(version, pKey...) 
  
      pKey = append(pKey, 0x01) 
 
      chksum := crypto.Sha256d(pKey)[:4] 
     
      pKey = append(pKey, chksum...) 
 
      w := base58.Encode(pKey)   

      fmt.Printf("WIF: %s\n", w)   

} 

1. Get the serialised private key 'd':

pKey := privKey.Serialise() 

2. Create an empty byte array, and append with either 1, or 5, depending on whether or not the WIF is for mainnet or testnet, respectively:

version := make([]byte, 0x80) //0xef for testnet 

version = append(version, 0x80) 

3. Append the serialised private key bytes to the byte array from step 2:

pKey = append(version, pKey...) 

4. Append the compression byte at the end to denote a corresponding compressed public key will be used:

pKey = append(pKey, 0x01) 

5. HASH-256 the byte array from step 4 and save the first 4 bytes:

chksum := crypto.Sha256d(pKey)[:4] 

6. Append the 4 checksum bytes from step 5 to the result from step 4:

pKey = append(pKey, chksum...) 

7. Encode the result of step 6 in Base58 (since the ‘Check' was added in step 6):

w := base58.Encode(pKey) 

8. Print result to standard out:

fmt.Printf("WIF: %s\n", wif) 

Activity – Generate a BSV WIF from a serialised private key

02e4f3975f6985c3cc20167fa0b38e649a67a66149844acc68b14eb361f510c2

Essentially, the Diffie-Hellman key exchange algorithm works by taking advantage of the unique mathematical properties of the modulo operation, or in other words, the logarithm space of a given power ‘nnn'. The modulo operation '%' yields the remainder after division: e.g. 4 mod 3=14 \ mod \ 3 = 14 mod 3=1. However, another way of looking at modulo is that it limits results to a certain space. For example, mod 2322^{32}232 or mod 2642^{64}264 are commonly used in computer science to constrain results to 32- or 64-bit integers because those are the largest integers computers can currently handle natively: uint32 and uint64. This means any number, or key, mod n will remain within the space of 0 to n.

First, two communicating parties agree on two numbers: a generator point ‘ggg', and a certain ‘order’ or modulo space 'nnn’ which must be a large prime number. Next, each party picks a random number (the larger, the better) which act as their private keys: aaa and bbb. They then use their private keys and the generator point ggg to calculate their public keys: A=ga mod nA = g^a \ mod \ nA=ga mod n and B=gb mod nB = g^b \ mod \ nB=gb mod n. Following that, they exchange their public keys in clear text over a public medium, and they can do so securely because so long as nnn is sufficiently large, it's computationally infeasible to find aaa or bbb from AAA or BBB even when ggg is known -- this is called the Discrete Logarithm Problem (DLP). Once the two parties have exchanged their public keys, all they need to do is exponentiate the other party's public key by their private key, and both parties end up with the same shared secret value 'svsvsv': sv=Ab mod n=Ba mod nsv = A^b \ mod \ n = B^a \ mod \ nsv=Ab mod n=Ba mod n.

For example, say Alice generates a private key ‘aaa' (currently these kinds of keys are 2,000 to 4,000 bits long for security), and Bob generates a private key 'bbb’. Knowing ggg and nnn, Alice can calculate her public key as ga mod ng^a \ mod \ nga mod n, and Bob his public key as gb mod ng^b \ mod \ ngb mod n, and, given a sufficiently large nnn (again 2,000 to 4,000 bits) it's impossible for anyone to figure out what aaa or bbb are without brute-force checking all the possibilities g1 mod n, g2 mod n,etcg^1 \ mod \ n,\ g^2 \ mod \ n, etcg1 mod n, g2 mod n,etc.

From there, Alice and Bob can exchange their public keys knowing it won’t expose their private keys, and then they can use the properties of exponentiation to derive the same secret value: sv=(ga)bmod n=(gb)amod nsv = (g^a)^b mod \ n = (g^b)^a mod \ nsv=(ga)bmod n=(gb)amod n

Similar to the Diffie-Hellman known parameters 'ggg' and 'nnn', DSA uses 3 parameters: 'ppp', 'qqq', and 'ggg'. ppp and qqq are randomly generated big prime numbers, where p−1p-1p−1 is a multiple of qqq. Like Diffie-Hellman, ggg is the generator point. First Alice and Bob generate a public-private key-pair a,Aa, Aa,A and b,Bb, Bb,B, respectively. Similar to Diffie-Hellman, these private keys are randomly generated numbers less than ppp, and their corresponding public keys are generator point to the power of the respective private key modulus ppp.

The two processes of signing a message 'mmm', and verifying the signature, then become:

Generate a random number 'kkk'

r=(gk mod p) mod qr = (g^k \ mod \ p) \ mod \ qr=(gk mod p) mod q

s=(k−1m+ar) mod qs = (k^{-1} m + ar) \ mod \ qs=(k−1m+ar) mod q

z=s−1 mod qz = s^{-1} \ mod \ qz=s−1 mod q

w1=m∗z mod qw_1 = m * z \ mod \ qw1​=m∗z mod q

w2=r∗z mod qw_2 = r * z \ mod \ qw2​=r∗z mod q

v=(gw1Aw2 mod p) mod qv= (g^{w_1}A^{w_2} \ mod \ p) \ mod \ qv=(gw1​Aw2​ mod p) mod q

v==rv == rv==r

sv=(ga)b mod 23072=(gb)a mod 23072sv = (g^a)^b \ mod \ 2^{3072} = (g^b)^a \ mod\ 2^{3072}sv=(ga)b mod 23072=(gb)a mod 23072

sv=g∗b∗a mod 2256=g∗a∗b mod 2256sv = g * b * a \ mod \ 2^{256} = g * a * b \ mod \ 2^{256}sv=g∗b∗a mod 2256=g∗a∗b mod 2256

Standard DSA signature computation for a hash of a message 'mmm' using private-public key-pair a,Aa, Aa,A:

aaa = random integer between 0 and 23072

A=g∗aA = g * aA=g∗a

Generate a random, 1-time use, key 'kkk'

r=(gk mod p) mod qr = (g^k \ mod \ p) \ mod \ qr=(gk mod p) mod q

s=(k−1m+ar) mod qs = (k^{-1} m + ar) \ mod \ qs=(k−1m+ar) mod q

ECDSA signature computation for a hash of a message 'mmm' using private-public key-pair a,Aa, Aa,A:

aaa = random integer between 0 and 22562^{256}2256

A=g∗aA = g*aA=g∗a

Generate a random, 1-time use, key 'kkk'

R=k∗gR = k * gR=k∗g

r=Rx mod qr = R_x \ mod \ qr=Rx​ mod q

s=(m+a∗r)k−1 mod qs = (m + a * r)k^{-1} \ mod \ qs=(m+a∗r)k−1 mod q

z=s−1 mod qz = s^{-1} \ mod \ qz=s−1 mod q

w1=m∗z mod qw_1 = m * z \ mod \ qw1​=m∗z mod q

w2=r∗z mod qw_2 = r * z \ mod \ qw2​=r∗z mod q

v=(gw1Aw2 mod p) mod qv = (g^{w_1}A^{w_2} \ mod \ p) \ mod \ qv=(gw1​Aw2​ mod p) mod q

z=s−1 mod qz = s^{-1} \ mod \ qz=s−1 mod q

w1=m∗z mod qw_1 = m * z \ mod \ qw1​=m∗z mod q

w2=r∗z mod qw_2 = r * z \ mod \ qw2​=r∗z mod q

v=(g∗w1)+(A∗w2)v = (g * w_1) + (A * w_2)v=(g∗w1​)+(A∗w2​)

vx==r mod qv_x == r \ mod \ qvx​==r mod q

To generate a Bitcoin public-private ECDSA keypair in golang using the :

Using the , generate a Bitcoin address for the following compressed public key:

Using the , generate a BSV WIF for the following private key 'd' value:

libsv libraries
hash calculator
hash calculator