Nostr Web Client

nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

can i ask you to take a look at this as well?

i have been meaning to ask an opinion on this (second) DLEQ from someone:

https://github.com/moonsettler/cashu/blob/dleq-por/docs/specs/40.md#alice-requests-dleq-proof-on-c

the idea is that the first DLEQ only proves that k private key was used to create C signature, if the r blinding factor is revealed because normally it only proves the relationship between B' and C'. this second DLEQ however is supposed to be a publicly verifiable proof that a token was signed by Bob without breaking unlinkability.

waxwing 2y ago

Hi, trying to get to grips with this now, a couple of questions:

first, why "Chaum-Pedersen commitment"? It's not a commitment scheme right, it's a proof (I think it's usually called, if not just DLEQ, then Chaum-Pedersen protocol. In Boneh and Shoup they introduce it as a proof of DH-triple-ness (I think we kind of half-discussed that in Telegram, I forget)).

Second, I'm kind of forgetting about a lot of the details of this Wagner scheme (that is now in cashu). The *first* DLEQ was part of the original description right? And the idea was somehow to let the user be confident that the token was valid or something? Even though they have to trust the issuer anyway?

So your second one is 'a publically verifiable proof that the token was signed by Bob without breaking unlinkability', and that's what you're asking for review about.

At first glance, I don't see how you're claiming unlinkability 'if Carol is secretly Bob'? Because Alice has to specify to Bob, the "C" and "Y" values (else he can't actually create the DLEQ, right?), so of course in presenting the tuple containing C, she reveals the link? Probably I missed something.

In general i think it's a good idea to be precise on both the inputs and outputs of the algorithm; in the case of this doc, you didn't for example write out the output tuple produced by Bob as the DLEQ (but also maybe specify sub-steps for actual clarity, what is known at the start, what is communicated etc.).

Reply to this note

Please Login to reply.

Discussion

moonsettler 2y ago

thanks for the correction, will fix!

yes, the first DLEQ Alice receives at the time the token is minted. however will not ask for the second immediately, that would be bad for her privacy.

so in theory it doesn't break unlinkability, because B' or C' can't be linked to C, and these two DLEQ-s don't happen in the same session. they would happen displaced in time. Someone would present C for Bob anyhow, Bob doesn't know if that is Alice or Carol. Bob may know that C' is related to a specific lightning invoice, but he has no idea that C is related to any such thing.

moonsettler 2y ago

ofc there are special cases where Bob would know that C' and C are related, for example if there is only one token in existence of his database of a certain denomination.

moonsettler 2y ago

let my try to explain it more succinctly what i'm trying to accomplish nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7!

the first DLEQ proves C' = k*B'

second DLEQ proves C = k*Y

it Alice gives Carol the first DLEQ Crol can't produce or verify C from it without r. r blinds the relationship between C' and C thus protects the 'unlinkability' aspect. Alice however can reveal the second DLEQ to anyone.