Re: [Lightning-dev] Lightning Mints
Good afternoon ZmnSCPxj, Thank you for your thoughtful reply! I agree with many of your points. One thing I wanted to say regarding the forces that act on banks: > It is helpful to remember that banks have, historically, been federations: > they are typically implemented as corporations, which are basically a bunch > of people pooling their money and skill together to start a business. > Thus, I argue that banks already *are* federations that take custody of your > money and manage it for you. > > To my mind, any system that is a federation that takes custody of user money > *will* face the same social, political, and economic forces that the legacy > banking system faced in the past. I actually think that banks operating on top of bitcoin may be subject to different forces. A major factor in the misbehavior of legacy banks has been lack of competition due to artificial barriers to entry due to regulation. I think in the absence of regulation, with competitors being able to enter the market at little cost, and without needing a license, we would see much less bad behavior from banks. I don't think that, aside from regulation, there is anything inherent to the business of banking that makes banks behave badly. If federated chaumian banks that interface exclusively with the Bitcoin and Lightning networks are able to evade regulators, the market for such banking services will hopefully see healthy competition between participants. This would be enhanced by the fact that such banks would be able to serve a global audience, and not be closely tied to a country, national currency, legacy settlement network, or region. > In addition, ti seems to me that the node management problem can be solved in > software, by something similar in purpose to CLBOSS. I think projects like CLBOSS are great, but I share elsirion's pessimism that LN node UX not be a fully soluble problem, no matter how good management software gets. Users will be choosing between services like Wallet of Satoshi, which are completely seamless, and it might not be possible for management software to fully abstract over things like high fees, uptime requirements, and unexpected fund unavailability due to channel closure. Best regards, Casey ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Lightning Mints
Good morning elsirion, > 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. Well, WabiSabi is effectively n-of-n signing, as the produced transaction has to be signed by all clients of the coordinator, so threshold federated signatures are not necessary. So yes, the use of credentials seems not possible to the federated mints project. (note: I am not a mathist and have no idea what the hell credentials are, I only know how to use them) > > 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. >From my PoV, any "bank-replacement" that is inherently custodial will >eventually become a bank, with all the problems that implies. It is helpful to remember that banks have, historically, been federations: they are typically implemented as corporations, which are basically a bunch of people pooling their money and skill together to start a business. Thus, I argue that banks already *are* federations that take custody of your money and manage it for you. To my mind, any system that is a federation that takes custody of user money *will* face the same social, political, and economic forces that the legacy banking system faced in the past. You puny humans simply do not evolve as fast as you think, you know --- your instincts still demand that your body stock up on fat and salt and sugar in a modern era where such things are available in too much abundance that it is killing you, so I imagine that a modern federated system (like Liquid or your federated mints) will face similar forces as past successful
Re: [Lightning-dev] Lightning Mints
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
Re: [Lightning-dev] Lightning Mints
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
Re: [Lightning-dev] Lightning Mints
Good morning again CAsey, > > I believe a major failing of Chaumian mints is that they are, at their core, > inherently custodial. > The mint issues blinded minted coins in exchaange for people handing over > other resources to their custody. > While the mint itself cannot identify who owns how much, it can outright deny > all its clients access to their funds and then run off with the money to > places unknown. > > However, do note that both Wasabi and WabiSabi are extensions of Chaumian > mints. > These avoid the custodiality issue of Chaumian mints by operating the mint as > a temporary entity, whose output is then counterchecked by the users of the > Wasabi/WabiSabi scheme. > > ... > > In any case, you might also be interested in the "nodelets" I described some > years ago. > This link has a presentation where I introduce nodelets towards the end, > sorry but most of the beginning is about LN pathfinding (which is currently a > non-problem since nobody makes published channels anymore). > This allows multiple users to implement a single node without a central > custodian, and may allow for similar flexibility of liquidity if there are > enough users, but every action requires all users to have keys online. Thinking more, it helps to consider how Wasabi and WabiSabi are constructed. In Wasabi, there exists a coordinator, which is a server that works as a temporary Chaumian mint. Clients of the coordinator register some UTXOs of some common value to the mint (indicating any change outputs if the UTXO total value exceeds the fixed common value). Then the coordinator issues blind signatures, which serve as tokens in a Chaumian mint. Then users re-connect via a different pseudonym, unblind signatures and reclaim the funds, indicating a target output address. The coordinator then creates a single transaction that consumes the registered input UTXOs and the indicated outputs. As a *final* step, the clients then check that the produced transaction is correct. This final step prevents the coordinator from absconding with the funds. 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. On issuing, the issuer can ensure that a particular value is encoded, then when the credential is blinded by the receiver, and the issuer can ensure that multiple credentials can be presented which sum up to a newly issued credential, with the value being correctly added. Thus, I think for a modern Chaumian mint, you should really consider the credentials scheme used by WabiSabi. -- 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). This coordinator in nodelets is simply a way to implement a broadcast medium among all the nodelets in a node. However, the same coordinator in a nodelets system can also serve as a coordinator in something very much like a WabiSabi system. So it seems to me that this can be implemented in a way that is non-custodial, as long as we can actually implement nodelets. (which "just" requires that we use a multiparticipant signing scheme for Schnorr signatures that is composable.) Basically, just as in the WabiSabi case, nodelets can connect to the coordinator, register some of the values they have in channels, then get back some equivalent credentials. Then the nodelets can "self-mix" their coins, then get back a new set of values, then request that some part of their value be sent over the network. Then, before signing off on the new state of any channel, the actual nodelets check the new state that the coordinator wants them to sign off on, thus preventing custodial risk in the same manner as Waasabi/WabiSabi does. Thus, each state update of the channel is created by a Chaumian mint (using credentials instead of blinded signatures), then the state update is "ratified" by the actual nodelets, preventing the Chaumian mint from stealing the funds; new states are simply not signed (and presumably one or more of the nodelets will drop the previous valid state onchain, which allows them to recover funds without loss) until all nodelets can confirm that the coordinator has not stolen anything. Nodelets can use pseudonyms in between states of channels, to reduce the ability of the coordinator, or the other nodelets, to guess who owns how much. An issue however is how to handle forwarding. Forwarding is an important privacy technique. If you are a forwarder, you can plausibly claim that an outgoing HTLC is not from your own funds, but instead was a forward. By supporting forwarding, the nodelets composing the node can reduce the ability of non-participants to determine the payments of the node. Handling forwarding in such a system
Re: [Lightning-dev] Lightning Mints
Good morning Casey, I believe a major failing of Chaumian mints is that they are, at their core, inherently custodial. The mint issues blinded minted coins in exchaange for people handing over other resources to their custody. While the mint itself cannot identify who owns how much, it can outright deny all its clients access to their funds and then run off with the money to places unknown. However, do note that both Wasabi and WabiSabi are extensions of Chaumian mints. These avoid the custodiality issue of Chaumian mints by operating the mint as a temporary entity, whose output is then counterchecked by the users of the Wasabi/WabiSabi scheme. I think a lot of problems are very easy if we go with custodiality; it is the variant rule of non-custodiality that makes this field interesting in the first place. Fidelity bonds are hard since the bond has to be at least the value of the funds being managed (otherwise the mint can still sacrifice the bond to run off with the funds being managed; it would still earn more than what it lost). That means, at best, locking up to twice the managed amount (i.e. locking it in a channel, *and* locking a similar amount in a separate fidelity bond). In any case, you might also be interested in the "nodelets" I described some years ago. This link has a presentation where I introduce nodelets towards the end, sorry but most of the beginning is about LN pathfinding (which is currently a non-problem since nobody makes published channels anymore). This allows multiple users to implement a single node without a central custodian, and may allow for similar flexibility of liquidity if there are enough users, but every action requires all users to have keys online. > I originally became interested in blind mints while thinking about Lightning > Network wallet usability issues. When Lightning works, it is fantastic, but > keeping a node running and managing a wallet present a number of challenges, > such as channel unavailability due to force closes, the unpredictability of > the > on-chain fee environment, the complexity of channel backup, and the involved > and often subtle need to manage liquidity. > > All of these problems *are* tractable for a skilled node operator, but may not > be soluble in the context of self-hosted wallets operated by non-technical > users, hereafter *normies*. If this is the case, then normies may have no > choice but to use hosted Lightning wallets, compromising their privacy and > exposing them to custodial risk. One of my projects is CLBOSS, which manages a C-Lightning node for you. * https://github.com/ZmnSCPxj/clboss * https://lists.ozlabs.org/pipermail/c-lightning/2020-October/000197.html The target is that at some point, the algorithms and heuristics developed for CLBOSS will be widespread and it would be trivial for a "normie" to run a well-managed forwarding node, they just have to keep it powered on 100% of the time, which should be easy, people keep their refrigerators powered on 100% of the time, after all. I am actually kind of puzzled that nobody else seems to be building node managers, everyone just focuses on peer selection, but ignores stuff like channel feerates, closing heuristics, liquidity monitoring, etc. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
