Just having a think about nostr and cashu. Please correct any mistakes in my assumptions:

1. You can send someone an encrypted message (NIP 4)

2. That message may simply be or contain a cashu token

3. Once sent, it is up to the receiver to claim that token against the mint?

4. With p2sh support, you could create a token that doesn't need to be claimed because spending is already restricted to the recipients private key so no need to even keep the token private.

5. Nostr effectively "solves" the storage and backup problem... No need for local backups.

6. You obviously still rely on a mint, but only for redemption of tokens and spending, not for account management or file backups.

7. The innovation is that now you only need to backup your private key (similar to on chain) but of course it is not fit for any sort of ling term storage, just resilient against phone loss or phone theft.

#[0] did I make any mistakes?

Reply to this note

Please Login to reply.

Discussion

I think might be on to something here. A few thoughts:

- NIP-4 only prevents other from reading the token. With P2SH, even if the token is locked to your private key, you'd need to know about it somehow. The best way of knowing is to receive the token. It can be NIP-4 encrypted, but it doesn't need to, that's true.

- However, the amount is still public and anyone could check with the mint whether the token was claimed or not. Now that I'm thinking about this though, it seems like this doesn't have to be that way. You could restrict "token checking" to only the one who can fulfill the P2SH spending condition. Thanks for that!

- So now that we've established that NIP-4 encryption doesn't hurt and also improve your privacy, you could, in principle, use this to "store" the tokens you've received. In a typical ecash transaction though, you'd immediately ask the mint for a new token when you receive it. This doesn't have to be though. You can let some time pass before you do that. If the token is not P2SH-locked though, it could be double-spent by the sender.

- I like the idea of tightly integrating nostr to an ecash wallet, however, I'm pretty sure that data storage on nostr will not remain totally reliable, especially if you're using free relays. I wouldn't want to rely on my relays not disappearing over night.

- There is also a privacy concern: even if you can send from a random nostr key, receiving would need to be from your private key. The mint and maybe everyone else would know that something is happening. This might be solved using some sort of shared secret between you and the sender (for which you'd need an interactive protocol though).

- If a network of mint providers would run nostr relays specifically to solve this UX problem though.... I'll have to think about it!

Thanks for the inspiration! Please feel free to keep thinking with us and share your thoughts :)

If encrypted by NIP 4, I suppose the privacy issue is gone since no one would know that you received a mint token?

I think so.

Perhaps some sort of analysis about the content length could suggest the presence of tokens? The tokens chars size is variable but I suppose it is prevedibile.

/cc #[4]