Nostr Web Client

Serialized pay-to-pubkey + DLEQ tokens will be around 846 chars long, or 150% longer than a normal Cashu token.

The benefit is that the payment will be final as soon as the data is received by the payee without a round trip to the mint. That

could mean ~10ms for a single atomic and final payment from user to user. 🤯

Is there any other payment system that is as fast?

https://void.cat/d/FNu9K42PCJfP9ZeTYCr52r.webp

waxwing 2y ago

Having recently looked at this, the construction is really cool but you don't yet have a solution for the proofs that (a) avoids time correlation between requests on the blinded token vs requests on the unblinded token, or (b) avoids requiring receiver to contact mint, right?

In an ideal world you could take a DLEQ (C'->B', A->G) and convert it (without mint's interaction) into a proof for C->Y instead ... the more naive ways of trying to do that involve making the DLEQ's security broken, I don't think it works. But in principle I think some (rather involved) ZKP, just using the discrete log primitives, *might* be possible. Essentially the sender claiming "Here is C, x, (and Y) and here is a ZKP that: I know a value r such that (C+rA)/(Y + rG) == A/G" without revealing r (all else is known/given to receiver).

Again, I'm not sure but, if it is indeed possible then I think it ticks all the boxes you're looking for.

Reply to this note

Please Login to reply.

Discussion

waxwing 2y ago

(Technical note: I use A/G as short hand for DL of A w.r.t. G).

By the way you can surely get more compact and powerful proofs of the type I describe above, by using bilinear pairings. But it is a lot of extra machinery. I think it's doable with just discrete log. (which is also nice because you can stick with secp256k1 and compatibility with btc/ln. you can't do that with pairings).

calle 2y ago

That's correct, none of the three options we explored were perfect:

1) Ruben's original DLEQ (C'->B', A->G) where we have to send r to the receiving user. This method allows the mint to link the token to the transaction it was created with if Carol and the mint collude. <-- this is what I used here.

2) "Stamps" that allow temporal correlation which would introduce a lot of complexity to avoid that, but if done optimally would avoid linking.

3) What I called "Schnorr Proofs" in the document I shared. This one requires sharing (B', C') to prove knowledge of r. Unfortunately (which I missed), (C', B') allows the mint to do the same thing as in (1) – so this option doesn't seem to improve anything but adds more data and validation cost.

I went with (1) for now because with this option, we can force the wallet do one transaction (i.e. re-mint) to obtain the token before it is sent to the receiver:

- peg-in with Lightning to create token1

- remint token1 for token2 (no link between them)

- send token2 to receiver including r

- mint can not link token2 to the Lightning payment

This method at least seems to allows unlinking token2 from the original Lightning transaction that lead to its existence.

A ZKP with those properties really would solve all of the issues that I can think of!

calle 2y ago

Note that 1 and 3 don't require another round trip to the mint to get the DLEQ but method 2 does, which is why I called it "temporal correlation" of the stamp on token2 to the creation of token1.

waxwing 2y ago

Right, I forgot about 1/ and the fact it has a different tradeoff, again. 2/ feels a lot closer to the spirit of unlinkability but you're right it's less practical, that much is clear.

I am not very optimistic about the ZKP idea; I tried to look at it for a few hours a few days ago, and this morning, kind of forgot how unpleasant it is ... it may not be possible with only classic DL-based sigma protocols, because it's not enough to prove something about 'r' but also about 'a' and you can't really malleate the proof you get from the mint without redefining the DLEQ in a way that violates its security.

I could be wrong though; it remains at least interesting to think about.