📅 Original date posted:2021-06-29
📝 Original message:
Hi,
> * WabiSabi uses KVACs which afaik do not allow client side validation. While I can't say if it will be a big problem it makes detecting certain failure scenarios harder imo.
> * The KVAC scheme referred to in WabiSabi [1] is not a threshold scheme afaik, undermining the central premise of federated mints. If I got that wrong this would be awesome!
Correct on both counts. Furthermore, WabiSabi is deliberately designed
for short lived credentials, since the entire nullifier set can be
discarded once a CoinJoin round terminates (successfully or
unsuccessfully). For longer lived tokens a generational/epoch based
approach is likely to be more practical.
Alternative credential schemes can be applied in a similar way, with
fairly minor differences in how attribute commitments are handled
(e.g. in the balance proofs)
- The ACL scheme[1] is publicly verifiable, but still relies on a
single issuer. see [2] for a wallet based on thereof, as well as the
cited works for some variations which rely on more general zero
knowledge proofs.
- The Coconut scheme [3] provides threshold issuance. I have not
studied this scheme in detail, but IIRC it only supports scalar
attributes (as opposed the KVACs used in WabiSabi, which also support
group elements. See also Danake [4] which relies on scalar attributes
only and uses epoch schemes.
Another related project is zkChannels (formerly and confusingly known
as BOLT) [5], the website hints at dropping the requirement for a new
opcode but no details appear to be available on the website yet.
[1] https://cs.brown.edu/people/fbaldimt/papers/CCS13.pdf
[2] https://eprint.iacr.org/2020/382.pdf
[3] https://arxiv.org/pdf/1802.07344.pdf
[4] https://lightweight.money
[5] https://boltlabs.tech/research
Yuval Kogman [ARCHIVE] /
npub1hk…u8g7t
2023-06-09 12:40:18
in reply to nevent1q…83zt
Author Public Key
npub1hkfafupgp66lck0q9zeumhypw9wq9ajakpznf6vd5jmhmcc6dnuqcu8g7tPublished at
2023-06-09 12:40:18Event JSON
{
"id": "e78368b9cbc94f15e1366ff06ab6fab5209f3fcb502f14dfb471adc8f173f411",
"pubkey": "bd93d4f0280eb5fc59e028b3cddc81715c02f65db04534e98da4b77de31a6cf8",
"created_at": 1686314418,
"kind": 1,
"tags": [
[
"e",
"b91c819991c63fe5a038a56a7e8130b74c7efbf4866b9437f2cb646ec4e0f33c",
"",
"root"
],
[
"e",
"44054890daaae29f62b9369466d8be76072aad7e490c3121cfd62ae0f9d680e0",
"",
"reply"
],
[
"p",
"de694f2ebea6b7f856c1bd060bf57ff8a6f4fa8523e5969db5b55864957d8f71"
]
],
"content": "📅 Original date posted:2021-06-29\n📝 Original message:\nHi,\n\n\u003e * WabiSabi uses KVACs which afaik do not allow client side validation. While I can't say if it will be a big problem it makes detecting certain failure scenarios harder imo.\n\u003e * The KVAC scheme referred to in WabiSabi [1] is not a threshold scheme afaik, undermining the central premise of federated mints. If I got that wrong this would be awesome!\n\nCorrect on both counts. Furthermore, WabiSabi is deliberately designed\nfor short lived credentials, since the entire nullifier set can be\ndiscarded once a CoinJoin round terminates (successfully or\nunsuccessfully). For longer lived tokens a generational/epoch based\napproach is likely to be more practical.\n\nAlternative credential schemes can be applied in a similar way, with\nfairly minor differences in how attribute commitments are handled\n(e.g. in the balance proofs)\n\n- The ACL scheme[1] is publicly verifiable, but still relies on a\nsingle issuer. see [2] for a wallet based on thereof, as well as the\ncited works for some variations which rely on more general zero\nknowledge proofs.\n- The Coconut scheme [3] provides threshold issuance. I have not\nstudied this scheme in detail, but IIRC it only supports scalar\nattributes (as opposed the KVACs used in WabiSabi, which also support\ngroup elements. See also Danake [4] which relies on scalar attributes\nonly and uses epoch schemes.\n\nAnother related project is zkChannels (formerly and confusingly known\nas BOLT) [5], the website hints at dropping the requirement for a new\nopcode but no details appear to be available on the website yet.\n\n[1] https://cs.brown.edu/people/fbaldimt/papers/CCS13.pdf\n[2] https://eprint.iacr.org/2020/382.pdf\n[3] https://arxiv.org/pdf/1802.07344.pdf\n[4] https://lightweight.money\n[5] https://boltlabs.tech/research",
"sig": "e6b267ea1d864892dce196c0bc5a4c2b9651151488a043a0712740c08a94fe30c8c0fba706d49bbb471217823037a65c3f134851deda8e2582ff45e897edd78e"
}