Itβs locked to the pubkey of the recipient; once you send the zap you canβt spend it anymore; only the recipient can.
Discussion
Goddit. Since the token is existing locally before being encrypted to a pukey, what prevents someone to create a client (or fork one) to include the option of keeping a not-encrypted version of the token locally, yhen psying by encryping it to pubkey. Then claiming back the not-encrypted version?
That's more an ecash-related question I guess
Also would like to know the answer to this.
"New" solves for the double spend problem have me suspicious.
But you're probably right that those are "eCash things" and that has a double spend solution already
Probably the solution is to bury these exceptions under the GUI, just like onchain wallets usually hide UTXOs already transferred even though the TX is not confirmed yet.
As of now I don't think that cashu can solve this double spending problem, because a token is just digital information...easily replicable
At 41:00 nostr:nprofile1qqs9pk20ctv9srrg9vr354p03v0rrgsqkpggh2u45va77zz4mu5p6ccpremhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet59uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcppemhxue69uhkummn9ekx7mp069f2j4 explains ecash double spend solution: https://fountain.fm/episode/aRawwvphCkYqxeS7EjOV
The token that exists before is destroyed (spent) when you lock to a pubkey, which results in a new token. The old token can not be spent again.
(It's not encrypted to a pubkey, it's *locked*, i.e., it's irreversible)
Okay so basically you burn an old token and ask the mint to create a new one locked to a pukey.
How is that supposed to work for offline transfers then? I saw something like that with cashu.me and offline transfers.
ON FIRE!!!!!!!