> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/key-derivation/0042.md). # BSV Key Derivation Scheme (BKDS) Ty Everett () ## Abstract This technical standard defines a key derivation method that allows two parties to derive multiple keys for each other in an open-ended manner. The method employs invoice numbers as a simple way for multiple keys to be derived. A sender can derive a public key for a recipient without knowing the recipient's corresponding private key, and the recipient can later use the sender's public key and the same invoice number to derive a corresponding private key. The method removes the limit of 4 billion keys per child that is present in BIP32[1](#footnote-1), improves the privacy of the involved parties by employing ECDH shared secrets, and enables an open-ended invoice numbering scheme for key derivation that can be further standardized for specific use-cases. The method can be used for private invoicing, digital signatures, symmetric cryptography, and other applications in Bitcoin and CBDC ecosystems. ## Motivation This technical standard addresses the need for a standard method for key derivation between parties that enables greater ecosystem interoperability. While BIP32[1](#footnote-1) provided a naive approach, it enabled only one key derivation universe per master public key. Conversely, this specification enables new key universes for every combination of two parties who interact, because the shared secret between their keys is employed. This also protects the privacy of the parties involved from outsiders who do not know the shared secret. The key derivation method offers several benefits. It enables two parties to derive many different keys for one another in an open-ended way, thereby providing greater flexibility. The use of invoice numbers as a simple way for multiple keys to be derived makes the method easy to use and enables further standardization. The method also employs ECDH shared secrets to improve privacy, and can be auditable by revealing shared secrets between specific counterparties to tax agencies for an audit to prove transactions. Additionally, higher-order protocol identifiers, key universes, and security levels within Bitcoin wallet and application architectures have been defined for this method. Overall, this key derivation method offers an improved approach to key derivation that can be used in various applications. It removes the limitations of existing key derivation methods such as BIP32[1](#footnote-1) and provides greater flexibility, privacy, and auditability. ## Specification The key derivation is specified as follows: ### Identity Keys Each party has a master private key and a master public key that are derived from the secp256k1 elliptic curve. ### Key Derivation * The sender computes the shared secret by multiplying his master private key with the recipient's master public key using elliptic curve point multiplication. * The sender uses the shared secret as the key to generate an HMAC over the invoice number. * The HMAC is then converted into a scalar using big-endian encoding. * The generator point G is multiplied by the scalar to generate a new point on the elliptic curve. * The resulting point is added to the recipient's master public key point to produce a new point on the curve. * The resulting point is then used to generate a new child public key. * To derive the corresponding private key, the recipient computes the shared secret by multiplying his master private key with the sender's master public key using elliptic curve point multiplication. * The recipient then generates the HMAC over the invoice number using the shared secret and computes the scalar in the same way as the sender. * The scalar is then added to the recipient's master private key to generate the corresponding child private key. ### Invoice Number The invoice number is treated as a string and is converted into a buffer using UTF-8 encoding. ### Steps for the Sender 1. The sender generates a shared secret by multiplying his master private key with the recipient's master public key using elliptic curve point multiplication. 2. The sender generates an HMAC over the invoice number using the shared secret as the key. 3. The HMAC is converted into a scalar using big-endian encoding. 4. The generator point G is multiplied by the scalar to generate a new point on the elliptic curve. 5. The resulting point is added to the recipient's master public key point to produce a new point on the curve. 6. The resulting point is then used to generate a new child public key for the given invoice number. ### Steps for the Recipient 1. The recipient generates the shared secret by multiplying his master private key with the sender's master public key using elliptic curve point multiplication. 2. The recipient generates the HMAC over the invoice number using the shared secret as the key. 3. The HMAC is converted into a scalar using big-endian encoding. 4. The scalar is added to the recipient's master private key (mod N) to generate the corresponding child private key for the given invoice number. ### Security Considerations BKDS requires master private keys to remain secret. Private-counterparty derivation also relies on the shared secret remaining confidential for its privacy properties. Access to a shared secret permits computation of its derivation tweaks and child public keys; by itself, it does not reveal a child private key. Derived private keys require the same protection as the master private key. #### Private-key containment and public counterparties BKDS is additive: `childPrivate = (masterPrivate + tweak) mod N`. Anyone who obtains both a child private key and its tweak can recover `masterPrivate = (childPrivate - tweak) mod N`. For BRC-43 `counterparty=anyone`, the tweak is public because the counterparty scalar is 1. Exposure of **any one** such child private key therefore compromises the master identity private key. Reusing one child across outputs does not change this risk; using unique children does not remove it. Master and derived private keys MUST remain inside a protected wallet or signer; they MUST NOT be exported to consumers or published in transactions, Scripts or messages. The master identity private key MUST NOT directly sign payments, Bitcoin transactions or application messages. Use an authorized protocol-derived child key through a signer/consumer interface such as [BRC-100](/wallet/0100.md), which returns no private scalar. Public-counterparty protocols MUST disclose the root-compromise consequence, identify the signing child key and require this separation before locking funds. Transaction and witness construction never justify exposing a private key. Signer separation reduces exposure; it cannot make a leaked child harmless. ### Conclusion This specification provides a method for key derivation that enables two parties to derive many different keys for one another in an open-ended way. This method employs invoice numbers as a simple way for multiple keys to be derived and uses the secp256k1 elliptic curve for key derivation. The method is designed to be flexible and auditable, with potential applications including private invoicing, ## Implementations This specification has been implemented in both the BSV [TypeScript SDK](https://github.com/bsv-blockchain/ts-stack/tree/main/packages/sdk) and [Go SDK](https://github.com/bsv-blockchain/go-sdk). ## Test Vectors Test vectors for this standard are provided: ### For Testing Private Key Derivation ```js [ { senderPublicKey: '033f9160df035156f1c48e75eae99914fa1a1546bec19781e8eddb900200bff9d1', recipientPrivateKey: '6a1751169c111b4667a6539ee1be6b7cd9f6e9c8fe011a5f2fe31e03a15e0ede', invoiceNumber: 'f3WCaUmnN9U=', privateKey: '761656715bbfa172f8f9f58f5af95d9d0dfd69014cfdcacc9a245a10ff8893ef' }, { senderPublicKey: '027775fa43959548497eb510541ac34b01d5ee9ea768de74244a4a25f7b60fae8d', recipientPrivateKey: 'cab2500e206f31bc18a8af9d6f44f0b9a208c32d5cca2b22acfe9d1a213b2f36', invoiceNumber: '2Ska++APzEc=', privateKey: '09f2b48bd75f4da6429ac70b5dce863d5ed2b350b6f2119af5626914bdb7c276' }, { senderPublicKey: '0338d2e0d12ba645578b0955026ee7554889ae4c530bd7a3b6f688233d763e169f', recipientPrivateKey: '7a66d0896f2c4c2c9ac55670c71a9bc1bdbdfb4e8786ee5137cea1d0a05b6f20', invoiceNumber: 'cN/yQ7+k7pg=', privateKey: '7114cd9afd1eade02f76703cc976c241246a2f26f5c4b7a3a0150ecc745da9f0' }, { senderPublicKey: '02830212a32a47e68b98d477000bde08cb916f4d44ef49d47ccd4918d9aaabe9c8', recipientPrivateKey: '6e8c3da5f2fb0306a88d6bcd427cbfba0b9c7f4c930c43122a973d620ffa3036', invoiceNumber: 'm2/QAsmwaA4=', privateKey: 'f1d6fb05da1225feeddd1cf4100128afe09c3c1aadbffbd5c8bd10d329ef8f40' }, { senderPublicKey: '03f20a7e71c4b276753969e8b7e8b67e2dbafc3958d66ecba98dedc60a6615336d', recipientPrivateKey: 'e9d174eff5708a0a41b32624f9b9cc97ef08f8931ed188ee58d5390cad2bf68e', invoiceNumber: 'jgpUIjWFlVQ=', privateKey: 'c5677c533f17c30f79a40744b18085632b262c0c13d87f3848c385f1389f79a6' } ] ``` ### For Testing Public Key Derivation ```js [ { senderPrivateKey: '583755110a8c059de5cd81b8a04e1be884c46083ade3f779c1e022f6f89da94c', recipientPublicKey: '02c0c1e1a1f7d247827d1bcf399f0ef2deef7695c322fd91a01a91378f101b6ffc', invoiceNumber: 'IBioA4D/OaE=', publicKey: '03c1bf5baadee39721ae8c9882b3cf324f0bf3b9eb3fc1b8af8089ca7a7c2e669f' }, { senderPrivateKey: '2c378b43d887d72200639890c11d79e8f22728d032a5733ba3d7be623d1bb118', recipientPublicKey: '039a9da906ecb8ced5c87971e9c2e7c921e66ad450fd4fc0a7d569fdb5bede8e0f', invoiceNumber: 'PWYuo9PDKvI=', publicKey: '0398cdf4b56a3b2e106224ff3be5253afd5b72de735d647831be51c713c9077848' }, { senderPrivateKey: 'd5a5f70b373ce164998dff7ecd93260d7e80356d3d10abf928fb267f0a6c7be6', recipientPublicKey: '02745623f4e5de046b6ab59ce837efa1a959a8f28286ce9154a4781ec033b85029', invoiceNumber: 'X9pnS+bByrM=', publicKey: '0273eec9380c1a11c5a905e86c2d036e70cbefd8991d9a0cfca671f5e0bbea4a3c' }, { senderPrivateKey: '46cd68165fd5d12d2d6519b02feb3f4d9c083109de1bfaa2b5c4836ba717523c', recipientPublicKey: '031e18bb0bbd3162b886007c55214c3c952bb2ae6c33dd06f57d891a60976003b1', invoiceNumber: '+ktmYRHv3uQ=', publicKey: '034c5c6bf2e52e8de8b2eb75883090ed7d1db234270907f1b0d1c2de1ddee5005d' }, { senderPrivateKey: '7c98b8abd7967485cfb7437f9c56dd1e48ceb21a4085b8cdeb2a647f62012db4', recipientPublicKey: '03c8885f1e1ab4facd0f3272bb7a48b003d2e608e1619fb38b8be69336ab828f37', invoiceNumber: 'PPfDTTcl1ao=', publicKey: '03304b41cfa726096ffd9d8907fe0835f888869eda9653bca34eb7bcab870d3779' } ] ``` ## Acknowledgments Credit is given to the people who have worked on making these ideas into reality. In particular, we thank Xiaohui Liu for creating the [first known implementation](https://gist.github.com/xhliu/9e267e23dd7c799039befda3ae6fa244) of private addresses using this scheme, and Dr. Craig Wright for first [describing it](https://craigwright.net/blog/bitcoin-blockchain-tech/offline-addressing). ## References * 1: [BIP32 Key Derivation Scheme](/key-derivation/0032.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://bsv.brc.dev/key-derivation/0042.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.