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.).
waxwing /
npub1va…knuu7
2023-05-10 14:53:28
in reply to nevent1q…ttny
Author Public Key
npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7Published at
2023-05-10 14:53:28Event JSON
{
"id": "123f170ea8563e13189af970a2bdc8e6d10dc6cc8f5cc42fd3a040277bf7e074",
"pubkey": "675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728",
"created_at": 1683730408,
"kind": 1,
"tags": [
[
"e",
"fcede4255321d02f2f1dfa3f8617646064ce1ecfb54748fd3fbec7cfa51435e2",
"",
"root"
],
[
"e",
"a2754a76060e03ecefbd2b9ee9c190de9e6be023a5140b574ef213269811a86a",
"",
"reply"
],
[
"p",
"6a3301c4584124c509efa3efeef04dfa4e7413032797fb79d0207689a085f10c"
],
[
"p",
"6a3301c4584124c509efa3efeef04dfa4e7413032797fb79d0207689a085f10c"
]
],
"content": "Hi, trying to get to grips with this now, a couple of questions:\n\nfirst, 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)).\n\nSecond, 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?\n\nSo 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.\n\nAt 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.\n\nIn 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.).",
"sig": "c2b24dca899ec5f34ed70b376702d4245ada67f2d5560eb3a3704b975d5299eb1e85fc19d9fdd2e076e16db6a662e13e0ac02d5792754385a8cc631d1f6f76c1"
}