The thing I don't understand about ecash is how it can be a bearer instrument and immune from double spends at the same time. It seems like the receiver would have to immediately redeem the token, and subsequent receivers to validate before accepting it in order for the latter problem to work. Am I right?
Discussion
nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uqs6amnwvaz7tmxxaazu6t09uqzp75cf0tahv5z7plpdeaws7ex52nmnwgtwfr2g3m37r844evqrr6j2vwkgf nostr:nprofile1qyghwumn8ghj7mn0wd68ytnvv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8rhwden5te0wfjkccte9ehhqetwvfskcctwvdjjuctswqhsz9nhwden5te0dehhxarjv4kxjar9wvhx7un89uqsuamnwvaz7tmwdaejumr0dshszythwden5te0dehhxarj9emkjmn99uqjzamnwvaz7tmyd968gmewdacx2mnzv9kxzmnrv5hxzurs9aex2mrp0yqzqp4hsxwh78rl23eprqnxa4au4pu9mn4wp83kagay4an9cmgasvnuvh3uhv
Not redeem but swap. Two different functions.
It seems to push the limits of the definition, for sure. Tokens can technically be exchanged offline, but the receiver would have to go online to verify with the mint that the tokens hadn't previously been spent, right? The source of truth preventing double-spending is still a trusted third party.
When someone receives ecash tokens, their wallet checks they are valid with the issuing mint. They do this by getting the mint to ” melt " the tokens to new tokens that are linked to their key. The paid tokens are then invalid at the mint and are useless to the payer, meaning that he cannot pay someone else because the mint won't melt them twice.
And in order to do this the receiver has to be online, right?
Not necessarily, if the token is tied to your public key, but it's a trade off, you need to trust the payer and the mint. Everything is a trade-off
One party has to be online to be trustless
If sender online they can lock the e-cash to receivers npub.
nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg
If it is a regular token you received then you go to the mint and immediately swap those tokens to have your own proofs that nobody else has. Until that time it is still double-spendable.
BUT if you have minted a P2PK token tied a specific pubkey then it can only be spent by unlocking that token with a signature just like in bitcoin p2pk.
These are also be swapped sometimes though upon receiving, depending on user needs: e.g. I want different coin denominations so I consolidate some tokens, or I want to have them in my own mint, in this case I melt them and deposit in my other more trusted mint.
Yes, that's indeed the standard protocol. The receiver immediately swaps the token against a new one with the mint.
The alternative flow is to lock a token to your pubkey and send it to you. Then, nobody can spend it except you so it can't be double-spent.
I'm not sure I quite understand yet, with p2pk it seems like asking a sender to lock a token to your pubkey would mean you can't spend your token without redeeming it. Unless you can chain these proofs? So if you have proof that the token was locked to the senders (b) key and in turn to yours (a), you know that the sender isn't double-spending, even if the person they received the token from (c) may have? But it basically increases the duration that the intermediary (b) would have to be working offline in order to get a double spend, and only the original sender (c) would be able to rug you.
It works very similar to Bitcoin. A Bitcoin address is essentially a public key and only its owner can spend coins on that address.
With ecash:
- the receiver shares a public key P with the sender
- sender locks ecash to P and sends locked ecash to receiver
- receiver looks at the ecash and sees "the ecash is signed by the mint and it's locked to P" -> it can only be spent by the owner of P (which is the receiver)
"locking" is like creating smart contract and attaching it to the token (it can't be detached). Not sure I understand your question but you don't need a proof, you just look at the contract to see the spending condition: pay to pubkey locked to P
Even if the sender would send it to anyone else, nobody can spend it except for the receiver. That's how publicly-verifiable nutzaps (NIP-61) work: I can post a token that's locked to your npub, everyone can see it, only you can spend it.
Does that answer your questions?
Here is the spec: https://github.com/cashubtc/nuts/blob/main/11.md
So locking has to happen online? I read the spec but am having a hard time grokking it all.
Yep, to lock a coin, you must burn one that you have, and in turn you create one that is locked – you must be online and communicate with the mint to do that.
Similar to sending your bitcoin into an address (that's only spendable by the receiver).
Interesting detail: the mint doesn't see what you're locking the token to, the token (and its locking script) is blinded when you do. Upon spending the coin (i.e. unlocking it), the mint sees the script it's locked to.
Soon TM we want to add zk-scripts so that the mint doesn't even see the unlocking script anymore. 2 weeks
Cool, so fully offline use basically depends on trusting the counterparty not to rug you for as long as you're offline. Do you see this impacting adoption in developing countries or low-trust scenarios?
Not exactly the case. One of the parties needs to be online to make a payment:
- if the receiver is online, send a normal token and receiver swaps
- if the sender is online, lock to receiver's pubkey and send
both transactions are final and can't be double-spent.
That's a good question, is it really a bearer instrument if it requires an interaction with a third party...?
The recipient needs to interact with a third party. Same as a bearer bond or a paper banknote on a gold standard.
I guess it's not the same, though, because a paper banknote can be exchanged many times and the laws of physics prevent double spends. Only the issuer and redeemer of the bank note need to interact with the bank. Secure use of ecash requires each intermediary to interact with the mint.
I think it still qualifies as a bearer instrument but with a lot more interactivity requirements. Of course, the devil is in the details. What do you need out of a bearer instrument that leads you to ask if ecash fits the definition? Rhetorical question.
