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

[a1denvalu3]

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.

[robwoodgate]

Tags entry must be included to ensure normalization is consistent

[robwoodgate]

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.

[robwoodgate]

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]

@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]

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

[robwoodgate]

@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]

@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.

[a1denvalu3]

@robwoodgate

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

Yes that's clear.

[robwoodgate]

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.

[a1denvalu3]

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)

[robwoodgate]

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

[robwoodgate]

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

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

[robwoodgate]

Couple more suggestions

[robwoodgate]

Re: c63aa7f 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]

as p2pk_r is now a Proof level concept

Maybe you're right.

[robwoodgate]

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 #300

[a1denvalu3]

Closing in favor of ECDH derived blinding factors