Nostr Web Client

Why use Cashu, then? The service operator will most likely not trust any other mints and use exclusively their own as that is the only one that can be trusted.

Instead of having a fully custodial system in that case you could look into channels where wrongdoing could be proved, something like the now-dead spec for “hosted lightning channels”

SatsAndSports 2w ago 💬 3

The service operator provides a list of mints that it trusts

"Fully custodial" doesn't really help when understanding cashu. While the mint can rug everybody yes, it is unable to rug *you* specifically, as it doesn't know who you are and it isn't able to link you to the server as it doesn't know who a given token was issued to

I don't know what you mean by "hosted lightning channel", I'll check it now. But without any link from you, I'll have to assume that it requires an onchain payment and therefore isn't practical when we might want to open channels to multiple servers every day and don't want to have to wait hours for confirmations

Feel free to implement that cashu-less alternative, I'd

Reply to this note

Please Login to reply.

Discussion

semisol 2w ago

It does not need an onchain channel

It is basically a custodial protocol that allows *proving* wrongdoing with a scheme similar to LN channels

The problem is that the service operator won’t trust any mint other than their own, if they can

SatsAndSports 2w ago 💬 2

How is that any better than cashu, from a risk-of-rug point of view?

The cashu folks are working on a proof of liabilities scheme to work alongside the obvious proof of reserves that mints could run (link below) . I haven't studied that yet, but I should and it might solve those problems

https://gist.github.com/callebtc/ed5228d1d8cbaade0104db5d1cf63939

SatsAndSports 2w ago 💬 1

And it's not a problem if the service provider trusts only one mint. We just need one mint that is trusted by both parties, and the negotiation to find a trusted mint could be done automatically

semisol 2w ago

The probability of a common mint approaches zero with more users and more service providers.

With each service wanting self-custody, the user would have to approve every mint for every service one by one.

semisol 2w ago

PoL has been "coming" for a while now, and could have been implemented many times in the last 2.5 years it was proposed. I still have yet to see an implementation of it.

The problem with all of these systems in general is that they are inefficient after a few payments per day and unnecessarily complex to implement.

For a service, custodians are very hard to trust, and using Cashu or similar schemes have a lot of potential failure paths and edge cases that can be handled. And a service running their own mint would not want to offer withdrawals.

At that point, you may as well use a credit stored in a DB. There is a reason you see disposable account numbers everywhere and ecash based systems nowhere: It is pointless and a hassle for the average user and the service.

You can always create a new account number for each payment.

SatsAndSports 2w ago

"A service running their own mint would not want to offer withdrawals"

Maybe, but then why would anyone use that service?

"PoL has been coming for a while now"

Maybe. But so have its alternatives 😃.

What's your alternative, that works today?

"inefficient after a few payments per day"

Where did that come from? The channel I'm working on allows dozens of payments to be made per second, where the recipient can immediately verify the signature and, assuming the receiver trusts the mint, they can unilaterally exit at any time. Even without this channel, I don't see how cashu can only do "a few payments per day"

If we accept some rug risk, cashu appears to be great at optimising other things (privacy, ease of use, and speed)

If you can point to an existing scalable solution that has zero rug risk, that is easier to use - and to develop for - than Lightning, then I'd like to see it

I love Ark, it does a lot of things very well, but the privacy isn't great there