NUT-XX: Pay-to-Blinded-Key (P2BK) #291

2025-10-02T07:57:09Z

a1denvalu3 commented

2025-10-02 07:57:09 +00:00

(Migrated from github.com)

Closes #290

This PR lays out rules for blinding locking keys in secrets with p2pk locking conditions.

Implementation only requires client side (wallet) additional logic.

# Closes #290 This PR lays out rules for blinding locking keys in secrets with p2pk locking conditions. Implementation only requires client side (wallet) additional logic.

prusnak (Migrated from github.com) reviewed

2025-10-02 11:17:18 +00:00

README.md

Is this removal intentional? It breaks table rendering

robwoodgate (Migrated from github.com) requested changes

2025-10-02 15:00:44 +00:00

robwoodgate (Migrated from github.com) left a comment

Tags entry must be included to ensure normalization is consistent

robwoodgate (Migrated from github.com) requested changes

2025-10-02 15:54:16 +00:00

26.md

					
				@ -0,0 +1,219 @@

				# NUT-26: Pay-to-Blinded-Key (P2BK)

2. Remove the r tag from meta.tags if present. If no tags remain, tags MUST be kept as an empty array (i.e: `tags: []`_

```suggestion 2. Remove the r tag from meta.tags if present. If no tags remain, tags MUST be kept as an empty array (i.e: `tags: []`_ ```

- Construct a P2PK Secret as in NUT-11 but replace all pubkeys with their blinded forms. The `tags` entry MUST be present, even if empty (i.e: `tags: []`). Blind the message as usual to obtain outputs and promises from the mint.

```suggestion - Construct a P2PK Secret as in NUT-11 but replace all pubkeys with their blinded forms. The `tags` entry MUST be present, even if empty (i.e: `tags: []`). Blind the message as usual to obtain outputs and promises from the mint. ```

- Normalize the Secret to P2PK (strip r; set kind = "P2PK"; ensure `tags` entry is retained if empty).

```suggestion - Normalize the Secret to P2PK (strip r; set kind = "P2PK"; ensure `tags` entry is retained if empty). ```

- Interop with NUT-11: All NUT-11 tag semantics (sigflag, n_sigs, locktime, refund, n_sigs_refund) apply unchanged when used with blinded keys. NUT-11 secrets intended for P2BK blinding MUST include the `tags` entry, even if empty (ie: `tags: []`)

```suggestion - Interop with NUT-11: All NUT-11 tag semantics (sigflag, n_sigs, locktime, refund, n_sigs_refund) apply unchanged when used with blinded keys. NUT-11 secrets intended for P2BK blinding MUST include the `tags` entry, even if empty (ie: `tags: []`) ```

robwoodgate commented

2025-10-02 16:03:30 +00:00

(Migrated from github.com)

The reference implementation for cashu-ts is currently in the v3-hackday branch of my own repo.

It is built on top of v3-alpha-2, so I'll PR it to v3-alpha-dev branch once we catch it up to my current v3 tip.

The reference implementation for cashu-ts is currently [in the v3-hackday branch of my own repo](https://github.com/robwoodgate/cashu-ts/commits/v3-hackday/). It is built on top of v3-alpha-2, so I'll PR it to v3-alpha-dev branch once we catch it up to my current v3 tip.

robwoodgate (Migrated from github.com) reviewed

2025-10-02 16:07:54 +00:00

README.md

Well spotted 👍

robwoodgate commented

2025-10-04 17:22:11 +00:00

(Migrated from github.com)

I've updated the cashu-ts implementation to handle Schnorr-derived pubkeys as well. This allows Nostr users to sign P2BK tokens locked with their 02-prefixed hexpub or NIP-61 pubkey.

We should probably document the Schnorr secret key derivation in this NUT, since it’s not as straightforward.

For compressed SEC1 keys, the public key includes its Y-parity bit, so the blinded secret key is always derived as (p + r) mod n. Simples.

For Schnorr, public keys are x-only with enforced even-Y parity, which means the original secret key p may have been
negated to ensure an even-Y public key.

So when deriving the blinded secret key for a blinded pubkey P', we need to check both candidates, (p + r) mod n and (-p + r) mod n, and select the one whose derived public key matches P' in the proof.

I've updated the cashu-ts implementation to handle Schnorr-derived pubkeys as well. This allows Nostr users to sign P2BK tokens locked with their `02`-prefixed hexpub or NIP-61 pubkey. We should probably document the Schnorr secret key derivation in this NUT, since it’s not as straightforward. For compressed SEC1 keys, the public key includes its Y-parity bit, so the blinded secret key is always derived as `(p + r) mod n`. Simples. For Schnorr, public keys are x-only with enforced even-Y parity, which means the original secret key `p` may have been negated to ensure an even-Y public key. So when deriving the blinded secret key for a blinded pubkey `P'`, we need to check both candidates, `(p + r) mod n` and `(-p + r) mod n`, and select the one whose derived public key matches `P'` in the proof.

a1denvalu3 commented

2025-10-05 11:41:20 +00:00

(Migrated from github.com)

@robwoodgate

So when deriving the blinded secret key for a blinded pubkey P', we need to check both candidates, (p + >r) mod n and (-p + r) mod n, and select the one whose derived public key matches P' in the proof.

Why didn't this problem emerge in the tests?

@robwoodgate > So when deriving the blinded secret key for a blinded pubkey P', we need to check both candidates, (p + >r) mod n and (-p + r) mod n, and select the one whose derived public key matches P' in the proof. Why didn't this problem emerge in the tests?

prusnak commented

2025-10-05 12:02:09 +00:00

(Migrated from github.com)

Why didn't this problem emerge in the tests?

just speculating: maybe the tests do not include this case? if that's true, we should add a case that triggers the need for this behavior

> Why didn't this problem emerge in the tests? just speculating: maybe the tests do not include this case? if that's true, we should add a case that triggers the need for this behavior

👍 1

robwoodgate commented

2025-10-05 15:00:00 +00:00

(Migrated from github.com)

@robwoodgate

So when deriving the blinded secret key for a blinded pubkey P', we need to check both candidates, (p + >r) mod n and (-p + r) mod n, and select the one whose derived public key matches P' in the proof.

Why didn't this problem emerge in the tests?

It did. I added tests for Schnorr derived keys when I found out P2BK wasn't consistently working with Nostr secret keys. Then I fixed it :)

> @robwoodgate > > > So when deriving the blinded secret key for a blinded pubkey P', we need to check both candidates, (p + >r) mod n and (-p + r) mod n, and select the one whose derived public key matches P' in the proof. > > Why didn't this problem emerge in the tests? It did. I added tests for Schnorr derived keys when I found out P2BK wasn't consistently working with Nostr secret keys. Then I fixed it :)

robwoodgate commented

2025-10-05 18:04:30 +00:00

(Migrated from github.com)

@robwoodgate

So when deriving the blinded secret key for a blinded pubkey P', we need to check both candidates, (p + >r) mod n and (-p + r) mod n, and select the one whose derived public key matches P' in the proof.

Why didn't this problem emerge in the tests?

And just to be clear, there was never an issue signing regular Schnorr pubkey locked proofs. It was just for P2BK where we have to derive an sk for a blinded Schnorr derived pubkey.

> @robwoodgate > > > So when deriving the blinded secret key for a blinded pubkey P', we need to check both candidates, (p + >r) mod n and (-p + r) mod n, and select the one whose derived public key matches P' in the proof. > > Why didn't this problem emerge in the tests? And just to be clear, there was never an issue signing regular Schnorr pubkey locked proofs. It was just for P2BK where we have to derive an sk for a blinded Schnorr derived pubkey.

robwoodgate (Migrated from github.com) requested changes

2025-10-05 18:38:45 +00:00

robwoodgate (Migrated from github.com) left a comment

Couple of minor nits, otherwise ACK @ ea6888e552

Couple of minor nits, otherwise ACK @ ea6888e552f1d6af786ab93cd3f53b550347f790

26.md

					
				@ -0,0 +1,219 @@

				# NUT-26: Pay-to-Blinded-Key (P2BK)

We should probably stay consistent with Cashu ecosystem and say '02' prefixed.

  - For BIP340 Schnorr/x-only contexts (e.g., Nostr), P is an x-only 32-byte pubkey (hex) with even-Y parity (per BIP340), prefixed with '02' for Cashu exosystem interoperability.

We should probably stay consistent with Cashu ecosystem and say '02' prefixed. ```suggestion - For BIP340 Schnorr/x-only contexts (e.g., Nostr), P is an x-only 32-byte pubkey (hex) with even-Y parity (per BIP340), prefixed with '02' for Cashu exosystem interoperability. ```

Pubkeys appearing in secrets should always be compressed SEC1 (33-byte hex) format.

- Blinded pubkey: P' = P + r·G. Encoding is compressed SEC1 (33-byte hex).

Pubkeys appearing in secrets should always be compressed SEC1 (33-byte hex) format. ```suggestion - Blinded pubkey: P' = P + r·G. Encoding is compressed SEC1 (33-byte hex). ```

a1denvalu3 commented

2025-10-05 22:52:46 +00:00

(Migrated from github.com)

@robwoodgate

And just to be clear, there was never an issue signing regular Schnorr pubkey locked proofs.

Yes that's clear.

@robwoodgate > And just to be clear, there was never an issue signing regular Schnorr pubkey locked proofs. Yes that's clear.

❤️ 1

robwoodgate (Migrated from github.com) approved these changes

2025-10-06 14:04:21 +00:00

robwoodgate (Migrated from github.com) left a comment

Thanks for merging my nit suggestions - sorry, I spelt ecosystem wrong in L23
Aside from my gaff - ACK @ e38faa0f86

Thanks for merging my nit suggestions - sorry, I spelt ecosystem wrong in L23 Aside from my gaff - ACK @ e38faa0f8690bd8c7b6f35b2ab72605dfc8963ae

robwoodgate commented

2025-10-07 15:01:15 +00:00

(Migrated from github.com)

I've added Cashu-TS with P2BK support (v3-hackday to #f3b9a9e) to Cashu NutLock, so we can play with it in the field. Cashu Redeem and Witness are also P2BK aware now.

TS files for these tools available here.

I've added Cashu-TS with P2BK support (`v3-hackday to #f3b9a9e`) to [Cashu NutLock](https://www.nostrly.com/cashu-nutlock/), so we can play with it in the field. Cashu Redeem and Witness are also P2BK aware now. TS files for these tools [available here](https://github.com/robwoodgate/nostrly/tree/main/src/js).

❤️ 1

a1denvalu3 commented

2025-10-07 19:46:13 +00:00

(Migrated from github.com)

Some topics that were discussed off-proposal:

We should rename r to p2pk_r
We should move p2pk_r in the Proof object, instead of the secret. Keep secret kind as "P2PK" and avoid any post-hoc normalization (do not break rules: secret stays the same).
There should be a way to signal "support" for blinded keys in a NUT-18 request.
(Potentially) We could NIP44-encrypt p2pk_r to the original public key, so only the intended receiver can actually see it (for use in public context, where the Mint could be tapping into)

Some topics that were discussed off-proposal: * We should rename `r` to `p2pk_r` * We should move `p2pk_r` in the `Proof` object, instead of the secret. Keep secret kind as "P2PK" and avoid any post-hoc normalization (do not break rules: secret stays the same). * There should be a way to signal "support" for blinded keys in a NUT-18 request. * (Potentially) We could NIP44-encrypt `p2pk_r` to the original public key, so only the intended receiver can actually see it (for use in public context, where the Mint could be tapping into)

👍 3

robwoodgate commented

2025-10-08 19:20:46 +00:00

(Migrated from github.com)

Have updated the reference implementation for cashu-ts to the agreed new format.

Renames r to p2pk_r
Moves p2pk_r to the Proof object, instead of the secret.
No longer mutates secret.
Adds nut26 flag to payment requests.
v4 token format uses pr key for p2pk_r
v4 token pr is encoded as an array of Uint8Array byte strings for better CBOR compression

Cashu NutLock and related Nostrly Cashu tools have also been updated to use this latest version.

Here is a sample P2BK token created with NutLock:

cashuBo2FteCJodHRwczovL21pbnQubWluaWJpdHMuY2FzaC9CaXRjb2luYXVjc2F0YXSBomFpSABQBVDwSUFGYXCBpWFhAWFzeQEUWyJQMlBLIix7Im5vbmNlIjoiNWYxN2U0MzU5YjFjZDAxYzkzNjQ4MGVkZGNjMGEzNzk2ZjJhYzM2MDVjNGIzOTkxZGE3YTQxY2UzNGE4MGY5OSIsImRhdGEiOiIwMzhiNTk0M2ZjMzY4ZjI1OWYzNTM5YTViN2FjMjE3ZjIzNzEwNzRkMzc1MDc3ZDMwNDZlMTk1NTkyYjI0Y2FjYTUiLCJ0YWdzIjpbWyJsb2NrdGltZSIsIjE3NTk5NjQzNDAiXSxbInJlZnVuZCIsIjAzNTJiOWFmNGJhMWRiMDliM2Y2Y2E1NDRhNmExY2M0OTQ1ZGRhZjY4MmZjOTMwMzYwYzVlZGU4NGQzZjNjNTBhYiJdXX1dYWNYIQKStW3NIERz0XR--cXYAkfmmo8iDigAc-2F8TE2MYhALGFko2FlWCDXvqR7-X6gJJiHa1T6eBaWHMnGMseti7OrXgwYGI3432FzWCBC6iVGhNhgqNPhA54qlYReHkNOMPHdRkPd2mlGykeB8GFyWCAsniO_fjxZSrh4lSelhNMkBZmMnDL1sdblE82YjYyjgmJwcoJYIHbeRz2-u06KCI0NMjMl75Vf5jnnmXcuONIg9ZVTefklWCAvZpnxoEhgKLdl9lFoU5bF-hVT8YsSmtrjO88OI0UUUw

Have updated the [reference implementation for cashu-ts](https://github.com/robwoodgate/cashu-ts/commits/v3-hackday/) to the agreed new format. - [x] Renames r to p2pk_r - [x] Moves p2pk_r to the Proof object, instead of the secret. - [x] No longer mutates secret. - [x] Adds `nut26` flag to payment requests. - [x] v4 token format uses `pr` key for `p2pk_r` - [x] v4 token `pr` is encoded as an array of Uint8Array byte strings for better CBOR compression [Cashu NutLock](https://www.nostrly.com/cashu-nutlock/) and related Nostrly Cashu tools have also been updated to use this latest version. Here is a sample P2BK token created with NutLock: ``` cashuBo2FteCJodHRwczovL21pbnQubWluaWJpdHMuY2FzaC9CaXRjb2luYXVjc2F0YXSBomFpSABQBVDwSUFGYXCBpWFhAWFzeQEUWyJQMlBLIix7Im5vbmNlIjoiNWYxN2U0MzU5YjFjZDAxYzkzNjQ4MGVkZGNjMGEzNzk2ZjJhYzM2MDVjNGIzOTkxZGE3YTQxY2UzNGE4MGY5OSIsImRhdGEiOiIwMzhiNTk0M2ZjMzY4ZjI1OWYzNTM5YTViN2FjMjE3ZjIzNzEwNzRkMzc1MDc3ZDMwNDZlMTk1NTkyYjI0Y2FjYTUiLCJ0YWdzIjpbWyJsb2NrdGltZSIsIjE3NTk5NjQzNDAiXSxbInJlZnVuZCIsIjAzNTJiOWFmNGJhMWRiMDliM2Y2Y2E1NDRhNmExY2M0OTQ1ZGRhZjY4MmZjOTMwMzYwYzVlZGU4NGQzZjNjNTBhYiJdXX1dYWNYIQKStW3NIERz0XR--cXYAkfmmo8iDigAc-2F8TE2MYhALGFko2FlWCDXvqR7-X6gJJiHa1T6eBaWHMnGMseti7OrXgwYGI3432FzWCBC6iVGhNhgqNPhA54qlYReHkNOMPHdRkPd2mlGykeB8GFyWCAsniO_fjxZSrh4lSelhNMkBZmMnDL1sdblE82YjYyjgmJwcoJYIHbeRz2-u06KCI0NMjMl75Vf5jnnmXcuONIg9ZVTefklWCAvZpnxoEhgKLdl9lFoU5bF-hVT8YsSmtrjO88OI0UUUw ```

robwoodgate (Migrated from github.com) requested changes

2025-10-09 19:03:44 +00:00

robwoodgate (Migrated from github.com) left a comment

Great work @lollerfirst, you've captured everything really well.

I've added a couple of suggestions for absolute clarity, but this is looking great.

Great work @lollerfirst, you've captured everything really well. I've added a couple of suggestions for absolute clarity, but this is looking great.

26.md

					
				@ -0,0 +1,219 @@

				# NUT-26: Pay-to-Blinded-Key (P2BK)

Tags if empty was only vital when we were mutating the secret. It can be optional now.

3. Build the P2PK secret as in NUT-11, substituting all pubkeys with the blinded versions $P'_i$.

Tags if empty was only vital when we were mutating the secret. It can be optional now. ```suggestion 3. Build the P2PK secret as in NUT-11, substituting all pubkeys with the blinded versions $P'_i$. ```

i don't really understand this requirement. I think it should probably be something like:

- Wallets MUST preserve ordering and SHOULD de-duplicate derived private keys that can sign the proof.

i don't really understand this requirement. I think it should probably be something like: ```suggestion - Wallets MUST preserve ordering and SHOULD de-duplicate derived private keys that can sign the proof. ```

SHOULD -> MUST?

  - BIP340 Schnorr/x-only contexts (e.g. Nostr): 32-byte x-only pubkey (hex) with even-Y parity (per BIP340). For Cashu interoperability wallets MUST prefix the x-only key with `02` when serialising to hex strings.

SHOULD -> MUST? ```suggestion - BIP340 Schnorr/x-only contexts (e.g. Nostr): 32-byte x-only pubkey (hex) with even-Y parity (per BIP340). For Cashu interoperability wallets MUST prefix the x-only key with `02` when serialising to hex strings. ```

- Wallets SHOULD reject proofs that advertise `p2pk_r` but do not contain the corresponding blinded keys. There must be one entry in `p2pk_r` for every blinded key.

```suggestion - Wallets SHOULD reject proofs that advertise `p2pk_r` but do not contain the corresponding blinded keys. There must be one entry in `p2pk_r` for every blinded key. ```

- Backwards compatibility: no mint changes are required. Legacy wallets can't redeem P2BK locked ecash, because they don't know how to derive the right private key(s) for the signature.

```suggestion - Backwards compatibility: no mint changes are required. Legacy wallets can't redeem P2BK locked ecash, because they don't know how to derive the right private key(s) for the signature. ```

a1denvalu3 (Migrated from github.com) reviewed

2025-10-09 20:35:38 +00:00

26.md

					
				@ -0,0 +1,219 @@

				# NUT-26: Pay-to-Blinded-Key (P2BK)

Ah probably can be removed altogether. Clanker sometimes likes to be verbose for no reason.

robwoodgate (Migrated from github.com) reviewed

2025-10-09 21:13:34 +00:00

26.md

					
				@ -0,0 +1,219 @@

				# NUT-26: Pay-to-Blinded-Key (P2BK)

Cashu-TS de-duplicates the derived secret keys, but it's not vital. Just saves some signing attempts.
Happy either way.

The important bit is "Wallets MUST preserve ordering of the p2pk_r array"

Cashu-TS de-duplicates the derived secret keys, but it's not vital. Just saves some signing attempts. Happy either way. The important bit is "Wallets MUST preserve ordering of the p2pk_r array"

robwoodgate (Migrated from github.com) approved these changes

2025-10-09 21:13:55 +00:00

robwoodgate (Migrated from github.com) left a comment

ACK

robwoodgate (Migrated from github.com) reviewed

2025-10-10 14:31:53 +00:00

robwoodgate (Migrated from github.com) left a comment

Couple more suggestions

26.md

					
				@ -0,0 +185,4 @@

				- Each $r_i$ MUST satisfy $1 \leq r_i \leq n-1$; randomness MUST be uniform and MUST NOT be reused across blinded keys.

				- Wallets SHOULD reject proofs that advertise `p2pk_r` but do not contain the corresponding blinded keys. There must be one entry in `p2pk_r` for every blinded key.

- Validate P, and later P′, as valid secp256k1 points and not the point at infinity before use.

```suggestion - Validate P, and later P′, as valid secp256k1 points and not the point at infinity before use. ```

26.md

					
				@ -0,0 +190,4 @@

				- Mint privacy: mints never learn the blinding scalars or the original pubkeys; spends appear identical to standard P2PK.

				- Freshness: reusing scalars enables linkage across blinded keys. Always use fresh randomness per key.

				- Metadata leakage: wallets MUST keep `p2pk_r` private between sender and receiver (do not leak to the Mint).

- Metadata leakage: wallets MUST keep `p2pk_r` private between sender and receiver (do not leak to the Mint).
- Where a P2BK proof is published in public (e.g: in a NutZap), the Mint _and any observer_ can immediately recover the clear public key $P$ from $P′$ and $r$. This removes the privacy benefits of P2BK, but does not compromise the security of the signing secret key ($p$).

```suggestion - Metadata leakage: wallets MUST keep `p2pk_r` private between sender and receiver (do not leak to the Mint). - Where a P2BK proof is published in public (e.g: in a NutZap), the Mint _and any observer_ can immediately recover the clear public key $P$ from $P′$ and $r$. This removes the privacy benefits of P2BK, but does not compromise the security of the signing secret key ($p$). ```

a1denvalu3 (Migrated from github.com) reviewed

2025-10-13 20:09:59 +00:00

26.md

					
				@ -0,0 +185,4 @@

				- Each $r_i$ MUST satisfy $1 \leq r_i \leq n-1$; randomness MUST be uniform and MUST NOT be reused across blinded keys.

				- Wallets SHOULD reject proofs that advertise `p2pk_r` but do not contain the corresponding blinded keys. There must be one entry in `p2pk_r` for every blinded key.

I think this is redundant, as the secp library already does this.

a1denvalu3 (Migrated from github.com) reviewed

2025-10-13 20:11:01 +00:00

26.md

					
				@ -0,0 +190,4 @@

				- Mint privacy: mints never learn the blinding scalars or the original pubkeys; spends appear identical to standard P2PK.

				- Freshness: reusing scalars enables linkage across blinded keys. Always use fresh randomness per key.

				- Metadata leakage: wallets MUST keep `p2pk_r` private between sender and receiver (do not leak to the Mint).

This follows logically from the previous point.

robwoodgate commented

2025-10-14 15:49:19 +00:00

(Migrated from github.com)

Re: https://github.com/cashubtc/nuts/pull/291/commits/c63aa7feda27502758e09b6321b95d25d8b3ba4a extending NUT10Options.

In Cashu-TS, I did a NUT-26 flag at the top level... as p2pk_r is now a Proof level concept, not a secret related one.

https://github.com/robwoodgate/cashu-ts/blob/v3-hackday/src/model/PaymentRequest.ts

It probably doesn't matter much either way, but as blinding is specifically a P2PK related concept, perhaps it should not be part of the generic NUT-10 options?

Re: https://github.com/cashubtc/nuts/pull/291/commits/c63aa7feda27502758e09b6321b95d25d8b3ba4a extending NUT10Options. In Cashu-TS, I did a NUT-26 flag at the top level... as `p2pk_r` is now a Proof level concept, not a secret related one. https://github.com/robwoodgate/cashu-ts/blob/v3-hackday/src/model/PaymentRequest.ts It probably doesn't matter much either way, but as blinding is specifically a P2PK related concept, perhaps it should not be part of the generic NUT-10 options?

a1denvalu3 commented

2025-10-17 08:20:31 +00:00

(Migrated from github.com)

as p2pk_r is now a Proof level concept

Maybe you're right.

> as `p2pk_r` is now a Proof level concept Maybe you're right.

d4rp4t (Migrated from github.com) approved these changes

2025-10-17 14:05:55 +00:00

robwoodgate commented

2025-10-19 21:51:09 +00:00

(Migrated from github.com)

NACK - I've been thinking about this, and am uneasy that the rs in the proof effectively render P2BK useless where they are posted publicly. Also, storing (up to) 11 rs per proof dramatically increases the size of the token.

So I've proposed an alternative blinding scheme, based on ECDH shared secrets.
PR https://github.com/cashubtc/nuts/pull/300

NACK - I've been thinking about this, and am uneasy that the `r`s in the proof effectively render P2BK useless where they are posted publicly. Also, storing (up to) 11 `r`s per proof dramatically increases the size of the token. So I've proposed an alternative blinding scheme, based on ECDH shared secrets. PR https://github.com/cashubtc/nuts/pull/300

a1denvalu3 commented

2025-10-20 10:05:06 +00:00

(Migrated from github.com)

Closing in favor of ECDH derived blinding factors

Closing in favor of [ECDH derived blinding factors](https://github.com/cashubtc/nuts/pull/300)