What about a zap protocol made with cashu tokens sent directly to the notes?
No need for an HTTP request to a third party, and the tokens can be parsed and validated by each client reader directly.
Discussion
Im probably not understanding the technical side well enough to get what would be different or better (from the user perspective) with this method?
Don't you need to check the token's validity with the mint?
Yep, the recipient will need to redeem the ecash with the mint in order to receive them. Probably an http call but any medium will work. It doesn't need to happen synchronously. This seems like a big improvement over lightning zaps. More private, more async, can all be done in the client.
The token can be issued with a commitment to the pubkey of the receiver that is enforced by the mint and that commitment can be verified by every reader, that's what nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg told me. This is very necessary for the protocol to work in a public environment.
We probably also have to check if the tokens are issued by the set of mints specified as trusted by the receiver.
?cid=586b07f0oanux45k4mphhm2nsn0izf17c70exrkdqzm1x71u&ep=v1_gifs_search&rid=200w.gif&ct=g And if the federated mint is a network of relay operators?
🤔
其实我一直觉得ecash比lightning更适合nostr，实现起来也更简单，可用场景也不止zap。
nostr:note1m7hguukwncsh7wdrc7adn6fwudl3agx7dphdlpgxxcrj08uexlkq3fl807
I've always seen Chaum's anonymous ecash system described in terms of RSA.
RSA has this ungainly patent which probably will be around for quite some
time, yet the Diffie-Hellman patent expires pretty soon. With that motivation,
here's a Chaumian anonymous ecash protocol based on Diffie-Hellman.
Take a publicly known group G and generator g; breaking Diffie-Hellman and
taking discrete logs in this group should be hard. For instance, G might
be (Z/pZ)^*, the integers modulo a prime p.
The bank picks a secret value k, and publishes g^k.
To withdraw a coin, Alice picks an x, sets
y = x | hash(x), [ | is concatenation ]
chosen so that y is in G. Alice chooses a random secret blinding factor b,
sends to the bank
A->B: y g^b,
and the bank returns
B->A: (y g^b)^k,
debiting Alice's account.
Note that this is a (blinded) Diffie-Hellman key exchange with public
exponentials g^k and y g^b; the bank returns the exchanged "secret".
Alice unblinds this value, computing
z = (y g^b)^k (g^k)^{-b}
and now c = (x,z) is a coin in the digital cash system. Note z = y^k.
We use the traditional online clearing protocol; to deposit the coin, a
shop S sends
S->B: x, z.
The bank checks to make sure the coin hasn't already been spent, and then
computes
y = x | MD5(x),
checking whether y^k = z. If equality holds, and the coin hasn't already
been spent, then the bank credits S's account and adds the coin to the
list of spent coins.
This is just the same old Chaum anonymous ecash protocol, except that I've
replaced the RSA operations by Diffie-Hellman ones. It's a lesser-known
fact that you can blind a Diffie-Hellman key exchange just as you can blind
a RSA signature.
The security of this protocol depends on the intractibility of breaking
Diffie-Hellman. In particular, given public exponentials g^k and y = g^m,
for k,m unknown, it must be impossible to compute g^{km} = y^k. Furthermore,
this protocol depends on the hash function being one-way and possessing no
interactions with Diffie-Hellman or modular exponentiation.
Comments?
[1] http://cypherpunks.venona.com/date/1996/03/msg01848.html
🤯
Related: nostr:nevent1qqsxgrxu5c9xfaacujczgf9epyfarhn89vam420yk4gsjhnn8acyjzspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8nhwden5te0dehhxarj94c82c3wwajkcmr0wfjx2u3wdejhgtcppemhxue69uhkummn9ekx7mp0qyv8wumn8ghj7mn0wd68ytnxd46zuamf0ghxy6t69uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshs3rnl5t (I hadn't seen this note)
It'd be REALLY nice to see a fully functional nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5-quality payment UI running on Cashu Backend inside of a nostr client. Especially if it can use any mint as the backend. Love this idea
nostr:npub1nz64zngcqm8vj8nhrdkcjpfwn2rcaqysnxec88tqfclp5afrpglsqm0w5y
yes