Oddbean new post about | logout
▲ ▼
nick | 8 months ago (raw) | root | parent | reply | flag 
 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.
▲ ▼
Gzuuus | 8 months ago (raw) | root | parent | reply | flag +1 
 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.
▲ ▼
nick | 8 months ago (raw) | root | parent | reply | flag +1 
 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
▲ ▼
Gzuuus | 8 months ago (raw) | root | parent | reply | flag 
 But the interaction its by the server, not by the user
▲ ▼
Erik | 8 months ago (raw) | root | parent | reply | flag +2 
 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.