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!