📅 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
AdamISZ [ARCHIVE] /
npub1nv…kqw2t
2023-06-09 12:58:46
in reply to nevent1q…uugz
Author Public Key
npub1nv7tjpn2g8tvt8qfq5ccyl00ucfcu98ch998sq4g5xp65vy6fc4sykqw2tPublished at
2023-06-09 12:58:46Event JSON
{
"id": "1a10578d4f985603b79bc3ebbdfc5a499805e3db558f7272714c06840359b0c8",
"pubkey": "9b3cb9066a41d6c59c090531827defe6138e14f8b94a7802a8a183aa309a4e2b",
"created_at": 1686315526,
"kind": 1,
"tags": [
[
"e",
"c218110e24b04f0c1c5d2dd6e63487b0dca619f1f570c991ff7f4dc7c65213bd",
"",
"root"
],
[
"e",
"9dd07a29ab853cd6232f288a33fc4d98f3c39465340a1fc81ae6120ed35167ad",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2020-02-12\n📝 Original message:\n\u003e 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.\n\nGood 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!\n\nI 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:\n\nhttps://github.com/privacypass/challenge-bypass-extension/blob/master/docs/PROTOCOL.md\n\nWhile 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.\nCheers,\nwaxwing",
"sig": "38ecb516d6312fcb0f2a0b5628b6c119720ffe6df905dcd04a38537fc617b116cbd17114257505818b1d823b355cd4288a1ef49dee9cd1c678463ce84be4946c"
}