AdamISZ [ARCHIVE] on Nostr: 📅 Original date posted:2020-02-12 📝 Original message: > One of the stated goals ...
📅 Original date posted:2020-02-12
📝 Original message:
> 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
📝 Original message:
> 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