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
  • Implementation
  • JavaScript

Was this helpful?

Edit on GitHub
Export as PDF
  1. Key Derivation

Mnemonic For Master Private Key

PreviousProtecting BRC-69 Key Linkage Information in TransitNextLinked Key Derivation Scheme

Last updated 1 year ago

Was this helpful?

Abstract

This is a simple extension of the widely used BIP39 Mnemonic seed phrase scheme where 12 to 24 words are used to encode entropy which is then used to derive an extended private key for use with the derivation scheme.

This document proposes a way to encode a single private key as a mnemonic phrase which people have become accustomed to.

Motivation

The purpose is to maintain the familiar interface to store a single key rather than an extended set. Users are already aware of the importance of keeping these words secret and secure, and have developed an awareness around not sharing them with a third party and so on. Rather than retraining users on a new concept, the idea is to do away with BIP32 in favor of BRC-42 style derivations, but keep the backup method for the master key as storing a mnemonic offline.

Note: There is no need to use BIP32 and BIP44 hereafter. You could just derive the first child key of an HD wallet and use that for BRC-44 derivations. However this is a simpler way to get to a single key and remains compatible with the menomics people may have been using for a decase now.

Overview

Using the standard BIP39 mnemonic scheme, a seed is created and can be maintained offline as words. Thereafter we must get from the mnemonic to a seed and then in this case to a private key. The simplest methodology can be used, a sha256 of the seed bytes is taken to arrive at the big number which is the private key.

Implementation

Using libsv/go-bk, we can generate a mnemonic, and derive the master key from it. All derivations for actual outputs can be derived using the scheme described in .

package main

import (
	"encoding/hex"
	"fmt"

	"crypto/sha256"

	"github.com/libsv/go-bk/bec"
	"github.com/libsv/go-bk/bip39"
)

func main() {
    // We generate some random bytes (any method for creating good random data can be used here).
	random, _ := bip39.GenerateEntropy(128)

    // The random data is encoded as a mnemonic of 12 words using the PBKDF2 function to SHA512 hash of the mnemonic sentence concatenated with the passcode (blank in this case).
	mnemonic, seed, _ := bip39.Mnemonic(random, "")
    // The private key is a sha256 of the seed bytes, this normalizes the output to 256 bits needed.
	privKeyBytes := sha256.Sum256(seed)

    // Here we ensure that using the mnemonic in future will result in the same private key.
	seed, _ = bip39.MnemonicToSeed(mnemonic, "")
	if privKeyBytes != sha256.Sum256(seed) {
        panic("mnemonic is invalid")
    }

    // Type cast a slice of bytes
	pkb := make([]byte, 32)
	copy(pkb, privKeyBytes[:])
	fmt.Println(hex.EncodeToString(pkb))
    // > '1ad0895dd317163f0e83499c30bc593dbcc54cad96a5f57b065ce9f700513250'

    // Create a PrivKey on the secp256k1 curve. 
	masterKey, _ := bec.PrivKeyFromBytes(bec.S256(), pkb)

    // Derive the corresponding PubKey and log it.
	pubKey := masterKey.PubKey()
	pubBytes := pubKey.SerialiseCompressed()
	fmt.Println(hex.EncodeToString(pubBytes))
    // > '021c2361fa1c39e21422b1374c2a08106f99b5425ada71f46f55b8e8e9d4a932db'
}

JavaScript

Same idea in js but we use bsv npm package, and a specific mnemonic to check we get the same resulting key pair:

import { PrivKey, PubKey, Bip39, Hash, Bn } from 'bsv'

const m = new Bip39(`dial tunnel valid cry exhaust stand match purse hope since demand palace`)
const seed = m.mnemonic2Seed().seed
const privateKey = Hash.sha256(seed)

const masterKey = PrivKey.fromBn(Bn.fromBuffer(privateKey))
console.log(masterKey.bn.toBuffer().toString('hex'))
// > '1ad0895dd317163f0e83499c30bc593dbcc54cad96a5f57b065ce9f700513250'

const pubKey = PubKey.fromPrivKey(masterKey).toString()
console.log(pubKey)
// > '021c2361fa1c39e21422b1374c2a08106f99b5425ada71f46f55b8e8e9d4a932db'
BRC-32
BRC-42