LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Overview
  • BIP32 Derivation Paths
  • BIP44 Wallet Addressing
  • Drawbacks and Alternatives
  • References

Was this helpful?

Edit on GitHub
Export as PDF
  1. Key Derivation

BIP32 Key Derivation Scheme

Abstract

This technical standard describes a method for hierarchical key derivation called BIP32. Hierarchical key derivation enables the generation of a large number of public-private key pairs from a single master seed, and the ability to derive child keys from parent keys in a deterministic manner. BIP32 is a widely used standard in various fields such as wallets, but has various limitations and drawbacks that should be considered carefully before further adoption.

Motivation

In many applications, it is necessary to generate a large number of public-private key pairs. However, generating and securely storing many keys can be challenging. Hierarchical key derivation solves this problem by generating an unlimited number of keys from a single master seed. This reduces the complexity of managing multiple keys and enhances security. BIP32 provides a standard for implementing hierarchical key derivation, ensuring interoperability between different systems.

Overview

BIP32 is a method for hierarchical key derivation that enables the generation of a virtually unlimited number of public-private key pairs from a single master seed. The master seed is used to generate the master private key, which is used to derive child keys. Child keys can in turn be used to derive grandchildren keys, great-grandchildren keys, and so on, forming a hierarchical tree-like structure.

Each key in the hierarchy is determined using a combination of its parent key and an index value. The index value determines the position of the key in the hierarchy, and the parent key serves as a starting point for deriving the child key. The combination of the parent key and the index value is used to generate a new private key, which can then be used to derive a new public key.

BIP32 specifies the use of a deterministic algorithm for deriving keys. This means that given the same master seed and index value, the same key will be generated every time. This is important for ensuring that different systems can generate the same keys, and for enabling secure backup and recovery of keys.

BIP32 also provides a standard for deriving hardened keys, which are child keys that cannot be derived from their parent public key alone. Hardened keys provide an additional layer of security, as they can only be derived using the parent private key.

BIP32 is a widely used standard for implementing hierarchical key derivation. It enables the generation of a large number of public-private key pairs from a single master seed, and ensures interoperability between different systems.

BIP32 Derivation Paths

BIP32 defines a hierarchical tree-like structure for generating an unlimited number of public-private key pairs from a single master seed. This structure is organized using a derivation path, which is a sequence of index numbers and hardened/not-hardened markers that uniquely identify a particular key in the hierarchy.

A derivation path always starts with the letter "m", which stands for "master", followed by a forward slash ("/") and then a series of numbers and markers that specify the child keys to be derived. For example, the path "m/0/1/2" indicates that the third child private key should be derived from the second child private key of the first child private key of the master key.

In addition to simple index numbers, BIP32 allows for "hardened" derivation, which means that the derived key can only be generated using the parent's private key. Hardened keys are denoted with an apostrophe (') after the index number. For example, the path "m/44'/0'/0'/0/0" is commonly used for generating the first receiving address of a Bitcoin wallet using BIP44 standard (discussed below).

BIP44 Wallet Addressing

BIP44 is a widely used standard for generating hierarchical deterministic wallets with a specific structure for addressing different cryptocurrencies. This standard provides a consistent method for generating and organizing addresses across different wallets and platforms.

The BIP44 structure uses a derivation path that starts with "m/44'/<coin_type>'/", where <coin_type> is a numeric identifier for the cryptocurrency being used. For example, "m/44'/0'/" is the path for generating Bitcoin keys, and "m/44'/60'/" is the path for generating Ethereum keys.

Following the coin_type index, BIP44 specifies several other indices to organize keys, including account, change, and address indices. Account indices are used to manage multiple accounts within a single wallet, change indices are used to differentiate between incoming and outgoing transactions, and address indices are used to generate unique receiving addresses.

For example, the path "m/44'/0'/0'/0/0" generates the first receiving address for the first account of a Bitcoin wallet. The "0'" after the coin_type index indicates a hardened key, ensuring that the derived key can only be generated using the parent's private key. The "0" after the hardened index specifies the first account, and the "0" after that specifies the first address in the account.

Drawbacks and Alternatives

While BIP32 is a widely used standard for hierarchical key derivation, there are several potential drawbacks that should be considered before further adoption.

One major limitation is that BIP32 lacks privacy guarantees. Since it is common for all child keys in a wallet to be derived from a single node, any knowledge of the root public key could compromise the privacy of the entire key hierarchy for the wallet — since public keys can be derived from parent public keys, there is a risk of linkability between addresses that use the same parent key.

Additionally, BIP32 is limited to a maximum of 2^31 possible child keys per parent, which may not be sufficient for applications that require a very large number of keys.

References

PreviousHTTP Transport for BRC-103 Mutual AuthenticationNextBSV Key Derivation Scheme (BKDS)

Last updated 8 months ago

Was this helpful?

To address these limitations, other key derivation schemes adopt various alternative approaches. By incorporating a shared secret between the sender and the recipient into the key derivation process, we can protect privacy even when the root public key becomes known. enables this functionality, and allows an unlimited number of child keys to be derived.

1:

BRC-42: BSV Key Derivation Scheme (BKDS)
BRC-42
1