> One of the stated goals of implementing PoDLEs was to be "compatible with 
> JoinMarket", but I believe this compatibility goal only extends as far as the 
> H2 construction (and not the proof), so we're ok there with this tweak.

Good point about H2 being cross-compatible, but I would not tie yourselves down 
in any way with attempting to keep compatibility with Joinmarket as-is, unless 
it's trivial to do so ... we will need to pretty much wholesale upgrade our 
protocol at some relatively soon point, ideally straight to schnorr/taproot, or 
if not, at least to native segwit, since coinjoin is a fee-heavy protocol. And 
there's a bunch of legacy stuff (especially in terms of encodings, but other 
stuff too) that will need to change. If you guys end up finding a stronger and 
clearer version of this podle/dleq thing and it ends up being useful, we will 
just tag along (at least, that's likely). And this is why I should not be lazy 
and try to keep up with this conversation!

I wanted to mention something else. Way back, maybe 2 years ago, I remember 
being interested that there *was* actually at least one use-case of DLEQ to 
create blinded tokens in the wild apart from our own. I dug up the link; it's 
really a beautiful idea but it's more based around a client-server model and 
using 'blind signing' (oblivious PRF based, so not old-style RSA or Chaum), but 
it's an easy idea to read and grok I think:

https://github.com/privacypass/challenge-bypass-extension/blob/master/docs/PROTOCOL.md

While it's very different from our use-case (harder because not client-server), 
it's still interesting that they use a DLEQ to prove correctly formed token 
construction, and then prevent 'double spend'. I wouldn't be surprised if there 
is something to learn from this line of thinking.
Cheers,
waxwing

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to