Deterministic pay to public key generation by lescuer97 · Pull Request #331 · cashubtc/nuts

lescuer97 · 2026-01-19T14:42:20Z

Adds a standard way to generate keys for wallets to generate private keys for usage in P2PK operations.

a1denvalu3 · 2026-01-19T14:46:04Z

+
+- 129372': Registered SLIP-0044 coin type for Cashu.
+- 10': Purpose for generating private keys for usage in P2PK.
+- {counter}: Incrementing counter encoded as an unsigned 64-bit integer in big-endian format.


is this using BIP32? Should be more clear.

yes, I'll make it clearer

a1denvalu3 · 2026-01-19T14:48:28Z

+
+Wallet are able to generate private keys to then have proofs be locked to them.
+
+The following path is used for derivation of those keys: `m/129372'/10'/0'/0'/{counter}`:


`m/129372'/10'/0'/0'/{counter}`:

not using per-keyset derivation. are we sure about this?

yes, because it's for locking up proofs it should be more general

robwoodgate · 2026-01-19T16:54:57Z

Keysets v2 is moving away from a BIP32 style derivation scheme, and using a KDF instead. Would it not be better to align with this approach, eg using a domain separator like b"Cashu_KDF_HMAC_SHA256_P2PK" or b"Cashu_P2PK_v1"?

Also, I assume the counter is separate to the one used for secrets/blinded messages. If so, this should be made clearer.

Finally, related to @a1denvalu3's comment - what happens if the derived key is out of range? Should it be discarded (as per BIP-32) or reduced modulo N?

prusnak · 2026-01-20T14:20:44Z

Keysets v2 is moving away from a BIP32 style derivation scheme, and using a KDF instead. Would it not be better to align with this approach, eg using a domain separator like b"Cashu_KDF_HMAC_SHA256_P2PK" or b"Cashu_P2PK_v1"?

Good point 👍

lescuer97 · 2026-01-21T12:59:43Z

@robwoodgate @a1denvalu3 just changed the wording around the NUT so it's a bit more clear.

robwoodgate

Suggestion to tighten language, otherwise concept ACK

robwoodgate · 2026-01-22T21:05:09Z

+- 10': Purpose for generating private keys for usage in P2PK.
+- {counter}: Incrementing counter encoded as an unsigned 64-bit integer in big-endian format.
+
+This will allow wallets to swap proof that are still locked to a public key during a restore process.


Suggested change

This will allow wallets to swap proof that are still locked to a public key during a restore process.

Wallets can deterministically generate private keys for P2PK using the following BIP32 derivation path:

`m/129372'/10'/0'/0'/{counter}`

Where:

- Purpose' = `129372'` (UTF-8 for 🥜)

- Coin type' = `10'` - reserved for generating private keys.

- `{counter}` is an Incrementing counter, encoded as an unsigned 64-bit integer in big-endian format.

This allows wallets to swap Proofs still locked to a corresponding public key during a restore process.

In line with BIP-32, if the resulting private key is out of range (`> N`), it should be discarded.

prusnak · 2026-01-22T22:13:07Z

+
+Wallet are able to generate private keys is a deterministic way to have proofs locked to them.
+
+The following BIP32 derivation path for derivation of the key: `m/129372'/10'/0'/0'/{counter}`:


Can you explain why the last element is not hardened?

Is the xpub of m/129372'/10'/0'/0' ever shared anywhere?

If it is not shared, then instead of hardening it, I propose we change the scheme to Cashu_KDF_HMAC_SHA256 (same as used in Keyset v2, since BIP32 used in Keyset v1 is deprecated).

We are following what Bitcoin does when it comes to key derivation for locking.

there is no reason right now for sharing an XPUB but can't guarantee that in the future.

The reason we want to use bip32 is because Bip32 is specifically made for this case.The Cashu_KDF_HMAC_SHA256 scheme is used because of aggregation to avoid certain issues when generating the keyset id.

This keys are never aggregated and are use individually.

The reason we want to use bip32 is because Bip32 is specifically made for this case.

No, it's not. BIP32 usecase is when you need to share a pubkey for a certain key subtree. Unless you need this requirement, going with Cashu_KDF_HMAC_SHA256 is simply faster and easier.

@prusnak if we get the option to query the mint for quotes connected to a pubkey via NUT-20, public key derivation would become more meaningful than it currently is. I can not think of a usecase right now, but with this, extended keys would be able to essentially create a watch-only wallet of a wallets quotes, without spending from it.

So either we think about proper usecases for this for 2 weeks and go with HMAC if we can't find any, or we take the performance L, go with BIP32 and hope someone finds a usecase some day in the future

if we want to have a watch-only wallet eventually which should show p2pk tokens too, this seems like a good use-case. ACK

The use case is double hypothetical - relying on wallets to export XPUBS and an endpoint that doesn't exist. BIP32 is a slowdown vs HMAC, a performance L to soak up forever.

And any lookup by pubkey would either be limited (pubkeys are SUPPOSED to be single use for privacy) or would likely allow the mint to link pubkeys (eg in a batch lookup scenario).

thesimplekid · 2026-03-27T14:16:00Z

 2. `hmac_digest = HMAC_SHA256(seed, message)`, where `HMAC_SHA256` is the [hash-based message authentication code](https://en.wikipedia.org/wiki/HMAC) using SHA-256 as the hashing algorithm.
 3. `secret = hmac_digest` and `blinding_factor = hmac_digest % N`.

+#### P2PK Derivation


I wonder of this should just be a new nut would be easier to track who supports it and think we should avoid changing existing nuts where we can especially widely supported ones like nut13. Though it would be a very small nut.

I thought about the same but I don't think it's needed in this case. Maybe if we start making more deterministic generation we would move it there.

robwoodgate

Honestly, I think we should use NUT-13's v2 HMAC-SHA256 KDF rather than introducing a new BIP32 path.

The KDF defined for v2 exists precisely because BIP32 path traversal is really expensive, and a P2PK private key only needs a uniform secp256k1 scalar, which the same single-HMAC + single-subtraction reduction (bias ~2⁻¹²⁸) gives you directly.

Quick numbers from a pure-JS noble benchmark (cashu-ts, per counter):

Pattern                                          Cost/key   vs HMAC
HMAC-SHA256                                       ~165 µs    1.0×
BIP-32 parent-cached, HDKey.publicKey             ~172 µs    1.0×    natural restore-loop code
BIP-32 master-cached, full path per derive        ~862 µs    5.2×    natural single-derive code
BIP-32 cold, no caching                          ~1216 µs    7.4×    worst case

In a restore situation, the wallet can cache the parent path derivation and get close to parity with HMAC, but if using just a cached master key (for regular wallet ops), the slowdown is 5x. In other words, BIP-32 needs careful handling to avoid performance tanking.

There is also no special need for BIP32 here: P2PK keys are derived wallet-side from a hot seed, so there's no hardware-wallet or chain-code benefit.

Mirroring the v2 construction — something like:

HMAC_SHA256(seed, "Cashu_KDF_HMAC_SHA256_NUT11" || counter_u64_be) reduced mod n

would keep a single KDF across all of NUT-13 and lines up with the direction v2 was already moving.

robwoodgate · 2026-05-29T16:14:08Z

I have proposed a HMAC-SHA256 KDF derived alternative, which would close this PR

robwoodgate

Following offline discussion, and the fact this is already live, I've closed #384.

pay to public key standard derivation

2ce332e

github-project-automation Bot added this to nuts Jan 19, 2026

github-project-automation Bot moved this to Backlog in nuts Jan 19, 2026

a1denvalu3 reviewed Jan 19, 2026

View reviewed changes

This was referenced Jan 19, 2026

Code improvements and better lining errors lescuer97/nutmix#219

Merged

P2pk receive wallet cashubtc/cdk#1466

Merged

a1denvalu3 reviewed Jan 19, 2026

View reviewed changes

fix: wording

75fa183

lescuer97 mentioned this pull request Jan 22, 2026

feat: follow deterministic derivation spec cashubtc/coco#68

Closed

This comment was marked as duplicate.

Sign in to view

robwoodgate reviewed Jan 22, 2026

View reviewed changes

prusnak reviewed Jan 22, 2026

View reviewed changes

SidepocketNeo mentioned this pull request Feb 2, 2026

Add topics for Socratic Seminar 155 (Thursday February 5, 2026) BitDevsNYC/BitDevsNYC.github.io#206

Merged

d4rp4t mentioned this pull request Mar 19, 2026

feat: p2pk keys deterministic derivation Kukks/DotNut#33

Draft

lescuer97 mentioned this pull request Mar 20, 2026

add test vectors cashubtc/coco#121

Open

thesimplekid reviewed Mar 27, 2026

View reviewed changes

use correct purpose and tests

04cce64

lescuer97 requested review from a1denvalu3, prusnak, robwoodgate and thesimplekid March 27, 2026 14:46

thesimplekid mentioned this pull request Mar 29, 2026

Extend NUT-13 to derive NUT-20 quote signing keys from seed #356

Open

robwoodgate suggested changes May 28, 2026

View reviewed changes

This was referenced May 29, 2026

add deterministic NUT-20 quote locking derivation #373

Open

NUT-XX: Deterministic Keypairs #384

Closed

robwoodgate approved these changes Jun 9, 2026

View reviewed changes


		Wallet are able to generate private keys to then have proofs be locked to them.

		The following path is used for derivation of those keys: `m/129372'/10'/0'/0'/{counter}`:

-This will allow wallets to swap proof that are still locked to a public key during a restore process.
+Wallets can deterministically generate private keys for P2PK using the following BIP32 derivation path:
+`m/129372'/10'/0'/0'/{counter}`
+Where:
+- Purpose' = `129372'` (UTF-8 for 🥜)
+- Coin type' = `10'` - reserved for generating private keys.
+- `{counter}` is an Incrementing counter, encoded as an unsigned 64-bit integer in big-endian format.
+This allows wallets to swap Proofs still locked to a corresponding public key during a restore process.
+In line with BIP-32, if the resulting private key is out of range (`> N`), it should be discarded.


		Wallet are able to generate private keys is a deterministic way to have proofs locked to them.

		The following BIP32 derivation path for derivation of the key: `m/129372'/10'/0'/0'/{counter}`:

Conversation

lescuer97 commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

robwoodgate commented Jan 19, 2026

Uh oh!

prusnak commented Jan 20, 2026

Uh oh!

lescuer97 commented Jan 21, 2026

Uh oh!

This comment was marked as duplicate.

Uh oh!

robwoodgate left a comment

Choose a reason for hiding this comment

Uh oh!

robwoodgate Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

prusnak Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lescuer97 Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

robwoodgate May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

robwoodgate left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

robwoodgate commented May 29, 2026

Uh oh!

robwoodgate left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

lescuer97 commented Jan 19, 2026 •

edited

Loading

robwoodgate Jan 22, 2026 •

edited

Loading

prusnak Jan 22, 2026 •

edited

Loading

lescuer97 Jan 26, 2026 •

edited

Loading

robwoodgate May 28, 2026 •

edited

Loading

robwoodgate left a comment •

edited

Loading