Nostr Web Client

I'd like your feedback on a cryptographic idea I have for Cashu. The idea is to allow Alice to blind a message, but where she cannot unblind it. Only the final recipient of the token, Carol, can unblind.

Using the Cashu protocol, where Alice is working with the mint (Bob), to prepare a token (x,C) which she will send to Carol. Let's define Carol's private key as 'f', with her public key as 'F=fG'

In the standard protocol, 'r' is a random integer selected by Alice. I propose instead that Alice selects a random integer r_. Instead of adding 'r*G' to Y in the third step (see the 'blinding' step in screenshot below), I propose that she instead adds 'r_ * F', to get 'B_ = Y + r_ * F'

This is equivalent to 'B_ = Y + r * G', where 'r = r_ * f'. Therefore, Alice has managed to blind it with 'r', but Alice doesn't know what 'r' is. Only Carol knows 'r', as only Carol knows 'f'. Carol is the only person that can compute 'r = r_ * f'

In the standard protocol, Alice unblinds and sends (x,C) to Carol. But here, Alice cannot unblind. Alice sends r_ and C_ to Carol instead. i.e. she sends (x, r_, C_) to Carol.

Carol can then reconstruct C, the 'unblinding' in the screenshot below, as 'C = C_ - r * K' , where 'r = r_ * f'.

Thoughts? While I have a background in maths, I'm very new to elliptic curves, so I'm assuming there's an attack surface that I'm missing.

Motivation: The original motivation is for 'deterministic outputs' in the Spilman channel that I'm working on with the Cashu folks (@calle), but this idea might also be useful in normal Cashu usage where the receiver (Carol) is offline. An offline receiver could publish their public key and the online sender can prepare a suitable 'BlindSignature' from the mint. Carol (and only Carol) is able to unblind and Carol can validate the DLEQ proof (NUT-12) offline

https://github.com/cashubtc/nuts/blob/main/00.md

Reply to this note

Please Login to reply.

Discussion

SatsAndSports 1mo ago

To state the motivation more clearly: it's to save fees compared to P2PK tokens in Cashu today

If I send you a Cashu token P2PK-locked to your public key, you will probably want to swap it to an anyone-can-spend token. This swap costs fees

In the approach above, you - and only you - can unblind the token. Therefore you have an anyone-can-spend token. Noone else has it and therefore you don't need to swap. Also, I think it has the same advantages as P2BPK

Pixel Survivor 1mo ago

Your fee optimization thinking could manifest as a single pixel at 33,33. After all that cryptographic elegance, the canvas offers simple, permanent math.

SatsAndSports 1mo ago

nostr:nprofile1qqsv8c37kh3aqrcckt60tzxcek79fpjghemphhvssyscdh6xq0tu42gpypmhxue69uhky6t5wdshgtnddakx7mnvv93x2tngdakxg6twvaej7qghwaehxw309a3xjarrda5kuetj9eek7cmfv9kz7qgwwaehxw309ahx7uewd3hkctc0g4qea, this idea is related to what we discussed yesterday about Spilman channels

I think I've found an alternative to P2PK , so we don't need the "stage 2" in what we discussed later

Instead of creating a P2PK token locked to your pubkey, I can create a normal anyone-can-spend secret which I can blind (using your pubkey), but only you can unblind (using your private key)

But I'll assume I've made a mistake somewhere, this almost seems too easy 🙂

c03rad0r 1mo ago

Aah yes, if I recall correctly, at the time we thought stage 2 wasn't necessary and we thought wallets were just doing it for the sake of storing unlocked proofs. I guess stage 2 did have a purpose which we were overlooking at the time then..

SatsAndSports 1mo ago

I think I've found the problem with what I propose at the top of this thread.

Alice can spend the same secret after sending it to Carol, by blinding the same secret in the conventional way and then spending it before Carol attempts to spend it

So that's why we need to stick with the two stages, both with P2PK

(I must admit I'm not sure I understand your response)

c03rad0r 1mo ago

I need to catch up quite a bit with my understanding of stage 2. I'll be sure to bring our older notes where you explained blinding/unbinding next time we meet 😀

Bugtus 6d ago

Oh yes, this is the attack I meant.

SatsAndSports 1mo ago

While Alice can't unblind on her own, there might be a problem because of the fact that Alice and the mint (Bob) can work together (because, between them, they know 'r_' and 'k') to unblind via:

C_ - r_ * k * F

Is this a problem?

Bugtus 6d ago

I don't think *this* is a problem. If Alice and the Mint collude they can always unblind C_, so this isn't really a downgrade from standard cashu.

However, there is an attack where Alice just lets the Mint sign Y twice. Once with Carol's public key B_ = Y + r * F and once the standard way with B_' = Y + rG.

Now, (x, r_, C_, DLEQ) looks like a valid token to Carol even when offline. However if Alice spends her token before Carol, Carol's token will get denied because the secret x is already in the Mint's spent set.

An idea to fix this:

1. Carol generates a bunch of secrets x, blinds them (B=Y+rG), and publishes these "Blank Checks" (B_'s) somewhere. She can then go offline.

2. Alice grabs a B_, pays the Mint to sign it (C_), and sends it to Carol. Alice cannot have Y signed twice (like in the prior attack) because she doesn't know x.

3. Carol receives C_ and the DLEQ proof. She verifies the proof against her original blank checks and the Mint's public key. If one of them passes, she has cryptographic proof that C_ is the valid signature for her specific B_. Since only she holds the secret x, she knows the token is safe and unspent. She can unblind it later when she is back online.

Not sure if I'm making any mistakes or the first step defies the purpose you want to use this for. I'm pretty new to all of this myself. Would love to hear what you think!

Bugtus 5d ago

Just realized that for the 'Blank Check' approach to work, we have to make sure that only a single party has access to a specific set of blank checks.

Otherwise, we run the risk that a check gets used twice but Carol can only redeem it once.

If we have to restrict access to the checks, that probably defeats the original purpose: 'An offline receiver could publish their public key and the online sender can prepare a suitable BlindSignature from the mint.'

Bugtus 6d ago

"She can *spend* it later when she is back online" not "unblind".