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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
