Nostr Web Client

With cashu there's always been a dilemma when sending ecash to someone: did they claim the payment?

Sure a wallet can ask the mint if a certain set of tokens were spent, but that creates a link between the sending and receiving wallet. It's a leak of information that loses you privacy.

A first solution, although maybe impractical, would be to let the mint stream the information about all the spent tokens to clients that request them (through apposite WebSocket endpoints).

So If I am a wallet and I have just sent some e-cash to someone, I can connect to the mint and "listen" until I am satisfied (until I know the e-cash was claimed).

This could put some pressure on the mint and it's not clear to me if it could be used to perform some DoS attack.

A better approach could leverage Nostr!

A mint with that advertises its associated `npub` on the `/v1/info` API endpoint could then regularly publish notes with all the information about freshly spent e-cash.

Clients would just have to query for notes with a `p` tag referencing the `npub` of the mint and look for the e-cash they just sent. Easy.

Reply to this note

Please Login to reply.

Discussion

David Caseria 1y ago

A WebSocket stream would quickly get out of hand on the server for a large mint. The Nostr integration is interesting as it effectively outsources the horizontal scaling of the WebSocket stream idea to relays. I can help if you want to collaborate.

x 1y ago

We could write a NUT. I assume some we can use some already established event kind (was thinking kind 30078, application-specific data) so as to avoid having to write a NIP as well.

David Caseria 1y ago

I'm a little confused about the intended use case for kind 30078 events. Is it meant for end-user applications? If so, would it be better to have a dedicated event kind for this instead?

What do you think about events for each operation: mint, melt, and swap? It would publicly announce the mint's liabilities and determine when a proof was claimed. I'm unsure if that's ideal or if it's expanding the scope too much. I'm also unsure how best to handle proof of assets and liabilities for a mint, but it may be best to figure out a comprehensive solution.

nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg do you have any thoughts?

x 1y ago

> What do you think about events for each operation

In theory it wouldn't benefit the PoL scheme but in practice maybe it could make it more feasible to execute, if that's what you were referring to.

David Caseria 1y ago

Good point. It probably makes more sense to keep this focused on your original idea

Felix 1y ago

Maybe the wallet could use Bloom filters so ask the mint about redeemed ecash tokens?

x 1y ago

I have already tried that. https://github.com/lollerfirst/nutshell/tree/sliding-bloom-filter

The mint could still link sender and receiver with high probabilityy.

conduition 1y ago

I agree about the DoS and scaling risks for websockets. Publishing data about spent proofs intermittently sounds more realistic to me, but I don't see any point in using Nostr to do that. A cashu mint is itself an always-on server already. What is gained by pushing that data to other people's servers besides offloading the DoS/scaling problems onto someone else? Instead the mint should just make that data available directly to clients via a new API endpoint.

Publishing one data point per spent proof wouldn't scale well - the mint needs some kind of accumulator or filter which compresses the information about spent proofs while allowing client-side validation. This seems like a use-case for Golomb-Coded sets (GCS), as used in BIP158 compact filters.

https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki

The mint computes a GCS which compresses all proofs spent recently, and updates the filter regularly. If the mint keeps the GCS hash representations sorted in memory, it could easily perform this update atomically for every single swap/melt without much of a performance hit (it'd be O(log n) insertion complexity).

If the filter gets too big, the mint compresses and archives it, and starts building a new one from scratch, or else evicts older GCS members (spent proofs) with a FIFO queue.

Clients can download and check the compact GCS filter at any time to see if their proofs have been spent recently, without revealing which ecash notes they're curious about. There's a chance for false positives but no chance of false negatives, so you might think your token was spent when it wasn't, but if your token was spent you'll always know about it.