Sounds like a pain in the ass. With the current system I don't have to deal with change.

The only (privacy) advantage of cashu is when tokens of a well establish get exchanged between users, for this narrow usecase that won't happen.

Reply to this note

Please Login to reply.

Discussion

Ah yes the privacy angle of ecash tokens is what keeps getting pitched to me but I didn't understand that a prerequisite was that the tokens needed to be getting exchanged between users. Can you explain that part a bit more?

It's not true. The only prerequisite is number of tokens can't be too small. If you are the only user, you are identified trivially for example.

Ah, so if I have a few thousand users using tokens that are only reedemable at my service, I still can't tell which users are spending which tokens. Is that correct?

Yes

Yes

Where is an easy place I can pay lightning invoice to get ecash tokens to use on routstr?

No, the users themselves are unknown to the service. No need to exchange between them, you can swap the tokens with the mint anytime.

You either deal with change, you get some strange credits or you have overhead.

But you can also stream cashu tokens without change, that also works. But a bit of unnecessary overhead for the mint.

That's fair, but it doesn't seem like a huge improvement with respect to the current situation where accounts are psuedonymous and cost nothing to create. And it does introduce new problems.

How would streaming work? Afaik the cost is known after the request is done

Websocket - pay for the next 100 tokens (send a prepared string), get next 100 tokens, pay for the next 100 tokens (send another prepared string), get next 100 tokens.

Or 10 or whatever.

But send and get change is basically acountless what you have. A little trust in the provider (same as with account model) and get refunded for not used credits.

Nothing to store at the server.