NUTXX - ECDH-derived Pay-to-Blinded-Key (P2BK) by robwoodgate · Pull Request #300 · cashubtc/nuts

robwoodgate · 2025-10-19T21:27:39Z

CLOSES #290
REPLACES: #291

Implementations:

Cashu-TS
- Original: ECDH derived Pay-to-Blinded-Key (P2BK) cashu-ts#377
- Revised: P2BK - Removes Keysetid and NUT-18 flag cashu-ts#465
CDK feat: P2BK cdk#1253
DotNut
- Original: Pay to blinded key (p2bk) Kukks/DotNut#21
- Revised: Chore/update p2bk Kukks/DotNut#28

Summary:

Defines P2BK as an ECDH-derived blinding scheme instead of one using random scalars.

Each proof now includes a per-proof ephemeral pubkey p2pk_e, from which both parties can derive the same blinding factor(s) deterministically.

ECDH shared secret works because:

Receiver long-term keypair: (p, P = p·G)
Sender ephemeral keypair: (e, E = e·G)
Shared secret: Zx = x(e·P) = x(p·E)   (32-byte x-coordinate)
Both compute the same point: e·p·G =  e·P = p·E

NOTE: Each receiver pubkey (P) has their own unique shared secret, and can ONLY derive their own.

Importantly, 3rd parties and the mint CANNOT derive the original locking pubkeys. Only the sender and the receiver have the secret keys required to calculate the ECDH shared secret, which can derive both the original pubkeys and the signing secret.

Proofs can be locked to a well known public key, posted in public without compromising privacy, and spent by the recipient without needing any side-channel communication.

Key points:

Adds p2pk_e (33-byte SEC1 pubkey) per proof (stored as pe in token v4 format)
Uses deterministic blinding:
rᵢ = SHA-256( b"Cashu_P2BK_v1" || Zx || keyset_id_bytes || i_byte)
where Zx is a shared ECDH secret, keyset_id_bytes is the hex_to_bytes of keyset ID, and i_byte is the P2PK locking key "slot" position.
No mint or protocol changes required.

Assumptions

The explicit 11 slot range (0-10) assumes the limits laid out in Secret and well-known secret lengths #255

Live Demo:

Create P2BK locked tokens using Cashu NutLock
Redeem P2BK using either Cashu Witness or Cashu Redeem

package-lock.json

d4rp4t

You've added a package.json file, propably by accident

robwoodgate · 2025-10-20T11:09:18Z

You've added a package.json file, propably by accident

Good catch - thanks @d4rp4t. Fixed

a1denvalu3 · 2025-10-22T23:05:38Z

@robwoodgate We should derive a Z_i for each locking key listed in the secret, so that the knowledge of one blinding factor doesn't necessarily imply knowledge of every other. This way, we can also throw away the slot indices ($i \in [0, 10]$).

Use case example:

Alice locks to Carol's public key with a locktime and a refund key. Carol can't unblind Alice's refund key.

I've opened a PR here

robwoodgate · 2025-10-23T04:44:01Z

@robwoodgate We should derive a Z_i for each locking key listed in the secret, so that the knowledge of one blinding factor doesn't necessarily imply knowledge of every other. This way, we can also throw away the slot indices ($i \in [0, 10]$).

Use case example:
Alice locks to Carol's public key with a locktime and a refund key. Carol can't unblind Alice's refund key.
I've opened a PR here

We already DO calculate shared secret (Zx) per locking key.

For each receiver key P, compute:
a. Slot index i in [data, ...pubkeys, ...refund]
b. Zx = x(e·P)
c. rᵢ = H("Cashu_P2BK_v1" || Zx || keyset_id || i) mod n
d. P′ = P + rᵢ·G

The slot index is just for ADDITIONAL uniqueness, so that if the same key (P) is added to both pubkeys and refund, it will be uniquely blinded by the slot index.

Only the sender knows the ephemeral secret, so only they can derive Zx per locking key (eP)

The receiver(s) only know the ephemeral pubkey (E) and their own secret key (p), so they can only generate the shared secret for their own key (pE).

EDIT: I've added some clarifying note blocks, because it's a crucial point that is easy to overlook.

a1denvalu3 · 2025-10-29T12:08:41Z

@robwoodgate I think we can avoid the p2pk_e entirely and instead use the nonce inside of secret more cleverly by setting it nonce = e*G.

robwoodgate · 2025-10-29T13:24:32Z

@robwoodgate I think we can avoid the p2pk_e entirely and instead use the nonce inside of secret more cleverly by setting it nonce = e*G.

Love this idea! That would be the ultimate privacy move because P2BK proofs would be totally indistinguishable from standard P2PK proofs. And making the E the nonce would effectively enforce wallets to ensure uniqueness per proof.

The only downside is the privacy benefit lol... there would be no way to know if a proof was blinded or not, so you would have to try signing EVERY P2PK proof that doesn't have your pubkey with both your secret key (p) and both your derived secret keys (p') to be sure it's not yours.

Overall, I think that's probably a tradeoff worth making for the privacy. And very in line with Bitcoin silent payments.

Anyone disagree?

robwoodgate · 2025-10-29T16:17:56Z

@robwoodgate I think we can avoid the p2pk_e entirely and instead use the nonce inside of secret more cleverly by setting it nonce = e*G.

Thinking about this some more this afternoon.... a possible reason to not do this:

if the Mint knows a P2BK E might be held in the secret nonce, could it possibly discriminate against P2BK proofs in some way by checking if the nonce is a valid curve x-coordinate?

(Though around half of all 32 byte string nonces would naturally be valid x-coordinates in any case...)

a1denvalu3 · 2025-10-29T16:41:04Z

@robwoodgate around ~ $\frac{1}{2}$ scalars are the x-coordinate to a public key. If the inputs to a TX are $n$, that gives $n$ independent ecash notes all having a valid public key in the nonce field. That has $\bigl(\frac{1}{2}\bigr)^n$ probability of happening randomly.

Though this could be easily fixed if newer wallets always use EC public keys as nonces, even for normal p2pk. The nonce field as of now isn't used for anything else than guaranteeing uniqueness between secrets locked to the same key.

robwoodgate · 2025-10-29T16:52:47Z

Though this could be easily fixed if newer wallets always use EC public keys as nonces, even for normal p2pk.

That would alleviate the discrimination concern for sure. It would also go some way to alleviating the related concern that using the secret.nonce would reveal ALL E's to the mint, not just those in proofs posted publicly.

a1denvalu3 · 2025-10-30T12:24:23Z

Discussed off proposal: SIG_ALL would break under P2BK conditions, because each Proof requires a unique E. SIG_ALL provides that all fields in the structured secret across all inputs/outputs (apart from the nonce) be the same, Therefore we have a conflict and SIG_ALL P2BK proofs wouldn't be spendable.

Two paths to resolution:

Make it so that E can be shared across a batch of SIG_ALL proofs. This option precludes the possibility of setting nonce = E inside the secret, as every nonce must be unique. Using p2pk_e degrades privacy because its possible for third parties (including the Mint) to single out P2BK proofs;
Forbid the use of SIG_ALL for P2BK proofs, and always set nonce=e*G for every NUT-10 secret (whether they are P2BK or not).

I would personally prefer option 2, especially given the Mint can find out who is using silent payments easily through option 1.

xx.md

robwoodgate · 2025-10-31T09:53:47Z

Discussed off proposal: SIG_ALL would break under P2BK conditions, because each Proof requires a unique E.

To summarize the dilemma:

Option 1: Carry `E` in the `Proof.p2pk_e` field

Pros

Allows P2BK SIG_ALL because the same E could be used across all the proofs to ensure all proofs carry the same tags as per SIG_ALL spec.
Ensures complete privacy for proofs that are NOT posted publicly, as the p2pk_e field is stripped before being sent to the Mint.
Signals a proof is using P2BK, so wallets need not try deriving keys for all proofs "just in case".

Cons

Signals a proof is using P2BK, allowing Mints to discriminate if the proof is posted in public (as the secret can be tied to P2BK, even if the p2pk_e is later stripped.)
Carrying an extra field increases token size

Option 2: Carry `E` in the `Proof.secret.nonce` field

Pros

Reduces changes to Proof shape and size - no extra p2bk_e field.
P2BK proofs posted in public LOOK like regular P2PK proofs, making discrimination harder (see caveat in cons).
Avoids the need to strip p2bk_e before sending to the Mint.

Cons

Prevents P2BK SIG_ALL because the same E cannot be used across all the proofs (nonce MUST be unique), and by extension, all proofs would not carry the same tags as per SIG_ALL spec.
Passes E to the mint in ALL cases (inc for proofs never posted publicly). This could possibly allow discrimination unless ALL NUT-10 secret nonces are required to be valid 33 byte points on the SEC1 curve.

EDIT - if we can specify NUT-10 nonces SHOULD be random 33-byte SEC1 pubkeys, then am also leaning towards Option 2.

robwoodgate · 2025-10-31T17:07:26Z

To summarize the dilemma:

Discussed again off proposal: The general feeling was to go with Proof.p2pk_e because:

Specifying NUT-10 nonces SHOULD be SEC1 compressed pubkeys would be a significant change to protocol
Precluding P2BK with SIG_ALL would be a big loss
Using the nonce field as a critical data carrier feels wrong ("Explicit is better than implicit")

Overall, reason 2 (loss of SIG_ALL compatibility) was seen as the main reason to NOT use the nonce as the carrier.

a1denvalu3 · 2025-11-03T07:59:54Z

@robwoodgate We could simplify the parity detection on the receiver side if we compared the x-only of the unblinded public key:
P' - r*G = -/+ p*G + r*G - r*G = -/+ p*G = -/+ P
Compare: x-only(P) == x-only(p*G)

But this is more of an implementation choice. We should however mention in the NUT that this is possible.

robwoodgate · 2025-11-03T11:09:31Z

@robwoodgate We could simplify the parity detection on the receiver side if we compared the x-only of the unblinded public key: P' - r*G = -/+ p*G + r*G - r*G = -/+ p*G = -/+ P Compare: x-only(P) == x-only(p*G)

But this is more of an implementation choice. We should however mention in the NUT that this is possible.

I don't think we need to mention implementation detail in the NUT.

In cashu-ts, the aim was to achieve algorithmic constant time, so both sk candidates are always calculated and the correct one chosen at the end.

1. Derive sk1, compute its pubkey
2. Derive sk2, compute its pubkey
3. Choose whichever sk derived the blinded pubkey P' or return nothing

You are correct the original pubkey P can be obtained once r is derived. I think you are proposing:

1. Derive unblinded P from P' and r
2. Compute the pubkey, see if it matches x(p.G) = x(P)
3. Compute pubkey using negated key, see if it matches x(-p.G) = x(P)
4. Derive sk using either p or -p, depending on the result above, or return nothing

It's not much of a simplifcation, as the blinded private key still needs to be derived in any case.

robwoodgate · 2025-11-03T11:21:27Z

@robwoodgate We could simplify the parity detection on the receiver side if we compared the x-only of the unblinded public key: P' - r*G = -/+ p*G + r*G - r*G = -/+ p*G = -/+ P Compare: x-only(P) == x-only(p*G)

But this is more of an implementation choice. We should however mention in the NUT that this is possible.

Overall, the parity detection issue is nothing to do with Pubkeys, it depends on whether the receiver secret key p is stored normalized for Schnorr or not. BIP-340 doesn't mandate (AFAIK) that a secret key should be normalized to the form that always creates even-Y pubkey, it only specifies that pubkeys be even-Y normalized.

So a wallet/Nostr client etc might allow a negative-Y generating sk to be stored, because it is flipped 'on the fly'.

We therefore will always need to check both for Schnorr derived pubkeys.

a1denvalu3 · 2025-11-03T12:14:59Z

It's not much of a simplifcation, as the blinded private key still needs to be derived in any case.

0. Pre-compute the public key: p*G
1. Derive unblinded P from P' and r: P = P' - r*G
2. See if the x-only matches: x(P) == x(p*G).
    2.a If it does, the first byte of the respective SEC1s tell you whether p or -p is to be used.
3. Compute either k_0 = p + r or k_1 = -p + r based on (2.a)

To me, this sounds like a semplification. You trade in 2 point-scalar multiplications and 1 point addition for 1 point-scalar multiplication and 1 addition.

robwoodgate · 2025-11-03T15:28:34Z

It's not much of a simplifcation, as the blinded private key still needs to be derived in any case.
0. Pre-compute the public key: p*G
1. Derive unblinded P from P' and r: P = P' - r*G
2. See if the x-only matches: x(P) == x(p*G).
    2.a If it does, the first byte of the respective SEC1s tell you whether p or -p is to be used.
3. Compute either k_0 = p + r or k_1 = -p + r based on (2.a)
To me, this sounds like a semplification. You trade in 2 point-scalar multiplications and 1 point addition for 1 point-scalar multiplication and 1 addition.

I understand now - yes, you can save a point multiply, and the approach is sound. I will revisit the cashu-ts reference implementation though for optimization.

robwoodgate · 2025-11-03T17:05:33Z

@robwoodgate We could simplify the parity detection on the receiver side if we compared the x-only of the unblinded public key: P' - r*G = -/+ p*G + r*G - r*G = -/+ p*G = -/+ P Compare: x-only(P) == x-only(p*G)

But this is more of an implementation choice. We should however mention in the NUT that this is possible. If we have one int the spec, it may as well be the optimal one.

@lollerfirst - I've now added this as the primary workflow. As we have one in the spec, it may as well be the optimal one!

robwoodgate · 2025-11-04T14:54:26Z

@lollerfirst - I've aded a comprehensive test vector page which will allow implementors to double-check a concrete example across all slots.

26.md

robwoodgate · 2025-11-06T20:26:27Z

@callebtc @thesimplekid - We now have implementations in review for Cashu-TS and CDK, so this PR is ready for review too. There is one question I have about whether we update NUT-18 to show p2pk_e as a default, LMK if I should add that.

robwoodgate · 2026-01-13T15:27:23Z

Filenames now set for immediate merge as NUT-28

SatsAndSports

Thanks for the last small changes. Looks good

00.md

28.md

callebtc · 2026-02-12T16:05:31Z

28.md

+
+ECDH allows two parties to create an x-coordinate shared secret (`Zx`) by combining their private key with the public key of the other party: `Zx = x(epG) = x(eP) = x(pE)`.
+
+For P2BK, the sender creates an ephemeral keypair (private key: `e`, public key: `E`). This protects the privacy of their own long-lived public key. They then calculate the shared secret by combining the ephemeral private key (`e`) and the receiver's long-lived public key (`P`).


This protects the privacy of their own long-lived public key.

we didn't define what the long-lived public key is yet (next sentence). we only speak about the receiver's pubkey but the sentence sounds like it protects the sender's pubkey. suggest to just remove the sentence.

That's exactly right - using an ephemeral keypair does protect the senders pubkey :)

callebtc · 2026-02-12T16:06:22Z

28.md

+
+ECDH allows two parties to create an x-coordinate shared secret (`Zx`) by combining their private key with the public key of the other party: `Zx = x(epG) = x(eP) = x(pE)`.
+
+For P2BK, the sender creates an ephemeral keypair (private key: `e`, public key: `E`). This protects the privacy of their own long-lived public key. They then calculate the shared secret by combining the ephemeral private key (`e`) and the receiver's long-lived public key (`P`).


Suggested change

For P2BK, the sender creates an ephemeral keypair (private key: `e`, public key: `E`). This protects the privacy of their own long-lived public key. They then calculate the shared secret by combining the ephemeral private key (`e`) and the receiver's long-lived public key (`P`).

For P2BK, the sender creates an ephemeral keypair (private key: `e`, public key: `E`). They then calculate the shared secret by combining the ephemeral private key (`e`) and the receiver's long-lived public key (`P`).

The idea here was to highlight to sender that using an ephemeral keypair protects their own (long lived) public key from being linked to the proofs.

We can remove the sentence, but I think it's an important feature of P2BK... it provides privacy for both sender AND receiver.

28.md

callebtc · 2026-02-12T16:09:20Z

28.md

+- `i_byte` is the single unsigned byte representation of `i`: (`0x00` to `0x0A`)
+- `||` denotes concatenation
+
+For broader compatibility, `rᵢ` **MUST NOT** be normalised modulo `n`


For broader compatibility, `rᵢ` **MUST NOT** be normalised modulo `n`

I know this issue (backwards compat) but why not? Every private key should be normalized.

I agree. I specced it modulo n in the intial draft, but received feedback that RUST (CDK) would have problems doing modulo n calculations.

So that's why it was re-drafted as "tweak-and-single-retry, abandon ephemeral key if still out of range"

Modulo n is the far simpler implementation, if it can be supported consistently.

That's the backwards compatibility issue. Happy to go either way - just make the call.

modulo n could technically give us 0 right?

It's so unlikely, I guess we could ignore it

But if we want to avoid that unlikely event, we could do modulo (n-1) and then add one

i.e. r = 1 + sha256(...) % (n-1) , where % is modulo, in order to ensure that we get a number between 1 and n-1 (inclusive). Although hopefully the cryptography library does something like this already

I believe the usual practice is to do standard modulo n and discard/retry if zero.

callebtc · 2026-02-12T16:09:46Z

28.md

+If `rᵢ` is not in the range `1 ≤ rᵢ ≤ n−1`, retry once with an extra `0xff` byte appended to the hash input as follows:
+
+```
+rᵢ = SHA-256( b"Cashu_P2BK_v1" || Zx || i_byte || 0xff )
+```
+
+If `rᵢ` is still not in the range `1 ≤ rᵢ ≤ n−1`, abort and discard the ephemeral keypair.


It would allow us to delete this part

28.md

callebtc · 2026-02-12T16:10:59Z

28.md

+  if (r === 0n || r >= secp256k1.Point.CURVE().n) {
+    // Very unlikely to get here!
+    r = bytesToNumber(
+      sha256(Bytes.concat(P2BK_DST, Zx, iByte, new Uint8Array([0xff]))),
+    );
+    if (r === 0n || r >= secp256k1.Point.CURVE().n) {
+      // Astronomically unlikely to get here!
+      throw new Error("P2BK: tweak derivation failed");
+    }
+  }


suggest: do not use own normalization, let the crypto lib handle it?

If RUST can handle the modulo n, it's a thumbs up from me. (@thesimplekid )

28.md

robwoodgate force-pushed the p2bk-silent branch from d98d9d6 to 58231b0 Compare October 19, 2025 21:33

robwoodgate mentioned this pull request Oct 19, 2025

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

Closed

d4rp4t reviewed Oct 19, 2025

View reviewed changes

package-lock.json Outdated Show resolved Hide resolved

d4rp4t suggested changes Oct 19, 2025

View reviewed changes

a1denvalu3 approved these changes Oct 20, 2025

View reviewed changes

d4rp4t approved these changes Oct 20, 2025

View reviewed changes

robwoodgate force-pushed the p2bk-silent branch from f665226 to 518522e Compare October 20, 2025 11:56

robwoodgate mentioned this pull request Oct 24, 2025

ECDH derived Pay-to-Blinded-Key (P2BK) cashubtc/cashu-ts#377

Merged

5 tasks

a1denvalu3 reviewed Oct 30, 2025

View reviewed changes

xx.md Outdated Show resolved Hide resolved

a1denvalu3 reviewed Oct 31, 2025

View reviewed changes

xx.md Outdated Show resolved Hide resolved

robwoodgate commented Nov 4, 2025

View reviewed changes

26.md Outdated Show resolved Hide resolved

Set NUT number to 28

d7e7ab8

SatsAndSports approved these changes Jan 13, 2026

View reviewed changes

ye0man added this to nuts Jan 13, 2026

github-project-automation bot moved this to Backlog in nuts Jan 13, 2026

ye0man moved this from Backlog to Needs Review in nuts Jan 15, 2026

d4rp4t mentioned this pull request Jan 19, 2026

Chore/update p2bk Kukks/DotNut#28

Merged

KvngMikey approved these changes Jan 27, 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

a1denvalu3 approved these changes Feb 11, 2026

View reviewed changes

d4rp4t approved these changes Feb 12, 2026

View reviewed changes