BSV Fundamentals

Module 2: Core BSV Blockchain Concepts

This module covers the core concepts and building blocks of the BSV blockchain. Understanding these fundamentals is essential for all BSV development.

Note: These concepts apply to both Backend and Frontend development paradigms. After completing this module, you'll choose your path:

Learning Objectives

By the end of this module, you will understand:

  • How transactions and UTXOs work

  • Public/private key cryptography

  • Addresses and their derivation

  • Bitcoin Script basics

  • Satoshis and denominations

  • Block structure and confirmations

  • SPV and blockchain verification

Core Concepts

1. Transactions

Transactions are the fundamental unit of activity on the BSV blockchain.

Structure

Key Points:

  • Transactions move value from inputs to outputs

  • Inputs reference previous outputs (UTXOs)

  • Outputs create new spendable UTXOs

  • Transaction ID (txid) is double SHA-256 hash

Example

2. UTXO Model

BSV uses the Unspent Transaction Output (UTXO) model, not an account model.

What is a UTXO?

A UTXO is:

  • An unspent output from a previous transaction

  • A discrete chunk of satoshis

  • Locked by a script (locking script)

  • Can only be spent once

UTXO vs Account Model

UTXO Model (BSV):

Account Model (Ethereum):

Benefits of UTXO Model

  • Parallel Processing: UTXOs can be processed independently

  • Clear Ownership: Each UTXO has explicit owner

  • Atomic Transactions: All inputs spent or none

  • Efficient Verification: Can verify without full state

Working with UTXOs

3. Public/Private Key Cryptography

BSV uses elliptic curve cryptography (specifically secp256k1).

Private Key

  • 256-bit random number

  • Must be kept secret

  • Used to sign transactions

  • Controls access to funds

Public Key

  • Derived from private key (one-way)

  • Can be shared publicly

  • Used to verify signatures

  • 33 bytes (compressed) or 65 bytes (uncompressed)

Key Properties

  • One-way derivation: Private → Public (easy)

  • No reverse: Public → Private (impossible)

  • Signatures: Only private key can sign

  • Verification: Anyone with public key can verify

4. Addresses

Addresses are human-readable representations of public key hashes.

Address Derivation

Creating Addresses

Address Formats

  • Legacy (P2PKH): Starts with 1 (e.g., 1A1zP1eP...)

  • Testnet: Starts with m or n

Important Notes

  • Addresses are not stored on blockchain

  • Only public key hashes are in locking scripts

  • Addresses are for human convenience

  • Multiple addresses can come from one public key

5. Satoshis and Denominations

Satoshi

The smallest unit of BSV:

  • 1 BSV = 100,000,000 satoshis

  • Named after Satoshi Nakamoto

  • All amounts are integers (no decimals on blockchain)

Denominations

In Code

Why Satoshis?

  • No floating point errors: Integer math is precise

  • Micropayments: Enable sub-cent transactions

  • Protocol native: Blockchain uses satoshis

6. Bitcoin Script

Bitcoin Script is a stack-based scripting language that defines spending conditions.

Locking Script (scriptPubKey)

Defines conditions to spend an output:

Unlocking Script (scriptSig)

Provides data to satisfy locking script:

Script Execution

Scripts are concatenated and executed:

Execution Steps:

  1. Push signature to stack

  2. Push publicKey to stack

  3. OP_DUP duplicates publicKey

  4. OP_HASH160 hashes publicKey

  5. Push expected pubKeyHash

  6. OP_EQUALVERIFY checks hash matches

  7. OP_CHECKSIG verifies signature

If script completes without errors and top of stack is TRUE, output can be spent.

Script Features

  • Turing complete (with some limitations)

  • Stack-based: Uses a stack for operations

  • Deterministic: Same input = same output

  • Flexible: Can create complex conditions

7. Blocks and Confirmations

Block Structure

Block Creation

  1. Miners collect transactions from mempool

  2. Build merkle tree of transaction IDs

  3. Find nonce that satisfies difficulty

  4. Broadcast block to network

  5. Other nodes validate and extend chain

Confirmations

  • 0 confirmations: In mempool, not in block (unconfirmed)

  • 1 confirmation: Included in latest block

  • 2 confirmations: One block built on top

  • 6+ confirmations: Generally considered final

Confirmation Time

  • Average block time: ~10 minutes

  • 1 confirmation: ~10 minutes

  • 6 confirmations: ~1 hour

8. SPV (Simplified Payment Verification)

SPV allows lightweight clients to verify transactions without downloading the full blockchain.

How SPV Works

  1. Download block headers only (~80 bytes each)

  2. Request merkle proofs for specific transactions

  3. Verify transaction is in block using merkle proof

  4. Trust the chain with most proof-of-work

Merkle Proofs

Benefits

  • Lightweight: Only headers needed (~80 MB for 1M blocks)

  • Fast: Quick verification

  • Secure: Cryptographic proof of inclusion

  • Mobile-friendly: Works on resource-constrained devices

SPV vs Full Node

SPV Client:

  • Downloads headers only

  • Requests proofs as needed

  • Verifies specific transactions

  • Suitable for wallets

Full Node:

  • Downloads all blocks

  • Validates all transactions

  • Maintains full UTXO set

  • Suitable for miners, services

The example below demonstrates how SPV verification enables you to cryptographically prove that a transaction is included in a block without downloading the entire block. You only need the block header and a Merkle proof.

Putting It All Together

Transaction Lifecycle

  1. Create Transaction

    • Select UTXOs to spend (inputs)

    • Create outputs for recipients

    • Create change output if needed

  2. Sign Transaction

    • Create unlocking scripts with private key

    • Sign each input

  3. Broadcast Transaction

    • Send to network via ARC or nodes

    • Transaction enters mempool

  4. Mining

    • Miner includes transaction in block

    • Finds proof-of-work

    • Broadcasts block

  5. Confirmation

    • Block added to longest chain

    • Each new block adds confirmation

    • After 6+ confirmations, considered final

Example: Complete Payment Flow

Important Note: This example shows the conceptual flow to understand how transactions work internally. In practice:

  • Frontend apps: Use WalletClient which handles all of this automatically

  • Backend apps: Use SDK's built-in methods for UTXO management, fees, and broadcasting

Conceptual Example (Understanding the Flow)

In Practice: Frontend with WalletClient

In Practice: Backend with SDK

Key Point: The detailed manual code above is for understanding the concepts. In real applications, the SDK and WalletClient handle UTXO selection, fee calculation, change outputs, and broadcasting automatically.

Key Takeaways

  • Transactions move value via inputs and outputs

  • UTXO Model enables parallel processing and clear ownership

  • Private Keys must be kept secret and control funds

  • Public Keys are derived from private keys and can be shared

  • Addresses are Base58-encoded public key hashes

  • Satoshis are the base unit (100M sats = 1 BSV)

  • Bitcoin Script defines spending conditions

  • Blocks contain transactions and build on previous blocks

  • Confirmations indicate transaction finality

  • SPV enables lightweight verification

Practice Exercises

  1. Generate Keys: Create a private key, derive public key and address

  2. Calculate Amounts: Convert between BSV and satoshis

  3. Understand UTXOs: Trace how UTXOs are created and spent

  4. Read Scripts: Interpret a P2PKH locking script

  5. Track Confirmations: Monitor a transaction from broadcast to 6 confirmations

Next Steps

Now that you understand BSV fundamentals, choose your development path:

Backend Development (Custodial)

You control private keys server-side

Continue to: Your First Wallet (Backend) - Learn server-side wallet management, UTXO tracking, and programmatic transaction creation.

Frontend Development (Non-Custodial)

Users control their own keys via wallet

Continue to: WalletClient Integration - Learn to connect to MetaNet Desktop Wallet and request user signatures.


Not sure which path? Review Development Paradigms to understand the differences.

Additional Resources

Last updated