Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 7
Generated: 12:56:51
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'. image 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
2025-11-29 11:39:31 from 1 relay(s) 5 replies ↓
Login to reply

Replies (7)

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
2025-11-29 11:58:52 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
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 🙂
2025-11-29 13:31:06 from 1 relay(s) ↑ Parent Reply
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?
2025-11-29 17:22:41 from 1 relay(s) ↑ Parent Reply
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..
2025-11-29 22:19:03 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
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)
2025-11-29 22:28:42 from 1 relay(s) ↑ Parent Reply