Hi ZmnSCPxj, let me chime in here, I've been working on federated mint for quite some time now but only recently began talking about it more publicly.
> WabiSabi "simply" replaces blinded signatures with blinded credentials. > Blinded signatures are fairly low-bandwidth ---- either you have a blinded > signature, or you do not. > Credentials, however, also include a blinded homomorphic value. This is a very intriguing idea Casey actually mentioned to me (at least I think it's about the same problem): In traditional mints we use tokens of the same denomination. For efficiency reasons amount tiers are introduced, reducing the anonymity set per tier. If we had blind signatures not only on random tokens but they also committed to a separately blinded amount with a range proof that would allow one big anonymity set over all tokens instead. Such tokens could then be combined similarly to Liquid transaction inputs. I think the concept is very interesting, but for now I see a few obstacles: * 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! * Building such an enhanced threshold blind signature scheme is more complex and probably needs further research. A naive implementation would be more interactive which in a federated context means waiting for consensus rounds for each round trip which is unappealing. So while I'm very sympathetic to the idea and want to pursue it in the future, threshold blind signatures seem like the more efficient way to get to a working implementation with still adequate performance and privacy in time. > Now, let us consider the "nodelets" idea as well. > The "nodelets" system allows for a coordinator (which can be a separate > entity, or, for the reduction of needed entities, any nodelet of the node). I didn't know of nodelets so far and went back to your 2019 post about it. It seems that blind multisig or threshold credentials (the idea seems to be m-of-m, so doesn't nee a general threshold scheme I guess) would improve the privacy of the system. I think the nodelets idea is very interesting for technical people that would otherwise be priced out of running a LN node in a high-fee future. But the complexity of the protocol and online requirements seem to make it suboptimal for non-technical, disinterested users. While automating a lot of the complexity away is possible (big fan of clboss) it's also a lot of work and probably will take a while if ever to get to a point where the experience is plug-and-play as most non-technical users have come to expect. In that sense both systems just have different target audiences. I think of federated mints mostly as a replacement for Banks and other custodial services that are used for their superior UX. It is fundamentally a compromise. E.g. Bitcoin Beach currently uses Galoy [2], a centralized hosted LN wallet without much privacy. I don't see a future where everyone there is technical enough to run their own node or nodelet client reliably enough. But if we can allow community driven federations with privacy built-in we can mitigate most of the risks inherent to custodial wallets imo. I really hope that I'm too pessimistic here, but if not I'd rather have a backup plan in the form of federated mints than letting banks eat our lunch. The idea is still early, but I hope some can agree with my reasoning. If so, come and help build this future with me [3]! Regards, elsirion [1] https://eprint.iacr.org/2019/1416 [2] https://github.com/GaloyMoney/galoy [3] https://fedimint.org/
publickey - elsirion@protonmail.com - 0xB3CDFF6F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
