[Lightning-dev] Lightning Mints

ZmnSCPxj ZmnSCPxj at protonmail.com
Mon Jun 28 05:40:28 UTC 2021


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




More information about the Lightning-dev mailing list