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
  • Identity Keys
  • Security Considerations
  • Key Derivation Process
  • Conclusion

Was this helpful?

Edit on GitHub
Export as PDF
  1. Key Derivation

Linked Key Derivation Scheme

Damian Orzepowski (damian.orzepowski@4chain.studio)

Abstract

The Linked Key Derivation Scheme builds on and extends the "type 42" key derivation method. This scheme allows public key derivation using only the public keys of both parties, maintaining the flexibility and unlimited key derivation of type 42. It aims to enable non-custodial wallets to derive public keys from a master public key without private key access, while only the master private key owner can derive the corresponding private key.

Motivation

The primary goal of this scheme is to enhance privacy and scalability in key derivation processes, enabling public key derivation based solely on the public keys of involved parties. Additionally, it ensures that the derived keys are linked back to their master keys, providing a mechanism for auditing and confirming the parties involved in transactions. This supports applications such as non-custodial wallets, ensuring secure and verifiable transactions without the need for private key access during the derivation process.

Identity Keys

The assumptions regarding identity keys remain unchanged from type 42. Each party has a master key pair, where the master public key is used to derive linked public keys. This ensures that the derived keys are linked back to the master key without requiring the master private key during the public key derivation process.

Security Considerations

The Linked Key Derivation Scheme maintains similar security properties to type 42, with the notable exception that no shared secret is generated or utilized. The scheme ensures that only the owner of the master private key can derive the corresponding linked private key, while public key derivation remains secure and private.

Key Derivation Process

Public Key Derivation:

flowchart
    A["Master Public Key (masterPubKey)"] --> B["HMAC(message = InvoiceNumber, key = Serialized Counterparty Public Key)"]
    B --> C[h = HMAC as big number]
    C --> D["H = h * G (Elliptic Curve Point)"]
    D --> E["LPK = masterPubKey + H (Derived Linked Public Key)"]
  1. Generate HMAC from the invoice number using the serialized public key as the key.

  2. Convert the HMAC to a scalar using big-endian encoding.

  3. Multiply the generator point ( G ) by this scalar to obtain a point on the elliptic curve.

  4. Add this point to the master public key (also expressed as a point) to get a new point on the elliptic curve.

  5. This new point represents the derived linked child public key.

Private Key Derivation:

flowchart
    A["Master Private Key (masterPrivKey)"] --> B["HMAC(message = InvoiceNumber, key = Serialized Counterparty Public Key)"]
    B --> C[h = HMAC as big number]
    C --> D["lpriv = masterPrivKey + h (Derived Linked Private Key)"]
  1. Generate HMAC from the invoice number using the serialized public key as the key.

  2. Convert the HMAC to a scalar using big-endian encoding.

  3. Add this scalar to the master private key (expressed as a number).

  4. This resulting number is the derived linked child private key.

Conclusion

The Linked Key Derivation Scheme provides a robust method for public key derivation, suitable for applications like non-custodial wallets, ensuring privacy, auditability, and secure key management without compromising security.

PreviousMnemonic For Master Private KeyNextBidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys

Last updated 9 months ago

Was this helpful?