ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-29 📝 Original message: Good morning elsirion, > ...
📅 Original date posted:2021-06-29
📝 Original message:
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 financial custodial federations (i.e. the banks of today).
Thus, it seems to me that with high probability, any custodial federated financial system will evolve to a similar state as banks today --- that is, cryptocurrency systems based on custodial federations will just "kick the can", and eventually be the same (with the same pros and cons) as modern banks.
This is not completely negative, since modern banks do provide vital services, but at the same time, one can argue that this is uninteresting in terms of exploration --- i.e. federated custodians have already been done before, they are the banks of today.
That is why CLBOSS exists --- it manages your money for you, but you run it on your own hardware and are responsible for auditing it, so it does *not* take control of your funds.
>
> 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]!
Well, I agree that kicking the can down the road is better as a backup plan than not having anything in case we really cannot find a reasonable way to make Bitcoin cheap and easy without losing noncustodiality.
Regards,
ZmnSCPxj
📝 Original message:
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 financial custodial federations (i.e. the banks of today).
Thus, it seems to me that with high probability, any custodial federated financial system will evolve to a similar state as banks today --- that is, cryptocurrency systems based on custodial federations will just "kick the can", and eventually be the same (with the same pros and cons) as modern banks.
This is not completely negative, since modern banks do provide vital services, but at the same time, one can argue that this is uninteresting in terms of exploration --- i.e. federated custodians have already been done before, they are the banks of today.
That is why CLBOSS exists --- it manages your money for you, but you run it on your own hardware and are responsible for auditing it, so it does *not* take control of your funds.
>
> 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]!
Well, I agree that kicking the can down the road is better as a backup plan than not having anything in case we really cannot find a reasonable way to make Bitcoin cheap and easy without losing noncustodiality.
Regards,
ZmnSCPxj