Yuval Kogman [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-29 📝 Original message: Hi, > * WabiSabi uses ...
📅 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
📝 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