Oddbean

▲ ▼

 were you the one that posted the cashu token with the extra character? I claimed it, think i replied but you mightnt have seen 😅https://m.primal.net/HlIK.png

▲ ▼

 I've done that before but was not my idea originally. Locking to npubs is the future, IMHO.

▲ ▼

 Makes sense for MITM thefts, but love the idea that the text is cash. Don't pass it to randoms!

▲ ▼

 Still, the text is the cash, but the cash is only usable by the pubkey that its blocked for 🤙

▲ ▼

 that makes it less cash-like imo, what if i want to redeem it without my pubkey? Or forward it to someone else without redeeming

▲ ▼

 Don't block it to a pubkey then, but if you want to make it public (like zaps) you would like to block it to a specific punkey

▲ ▼

 True definitely makes sense there!

▲ ▼

 Thinking again, why lock rather than encrypt?

1) encrypt an ecash token to a pubkey, send in note
2) recipient decrypts, claims, and reveals the decryption in another note such that everyone can see the zap.

Probably been discussed elsewhere, i havent been following any ecash-zap commentary.

▲ ▼

 The ecash-zaps conversation is something new, I don't know if there's been more discussion about it, but afaik it's something that's happening live. Maybe @calle 👁️⚡👁️  can tell us a bit more.

But I think the p2pk option and locking to a public key makes sense for this use case because it makes the process non-interactive for the receiving user and yet I imagine you can know the value of the nut. This way the clients could account for that value, because we assume that the nut can only be used by that user and no other user can spend it, so clients can account for that and display it like the current zaps.
Encrypting it is a valid option, but requires user interaction to decrypt it and then add a step to make the nut/value public(?). I think p2pk would be more suitable for this use case.

▲ ▼

 Zaps are already interactive with zap receipts, but it would be nice if they weren't
https://github.com/nostr-protocol/nips/blob/master/57.md#appendix-e-zap-receipt-event

▲ ▼

 But the interaction its by the server, not by the user

▲ ▼

 You also guarantee that the token hasn't already been spent.  An encrypted token may have been sent out multiple people, the p2pk one can only be redeemed at the mint by you.