pull down to refresh

If the receiver isn't online, who custodies the ecash when you send it to them?
The best you can do is bind the notes to a receiver's keypair, but that requires the receiver to trust the sender's mint until they come online (a delayed, possibly fraudulent promise of settlement) ... unless you send to the receiver via lightning which is #752528.
Yep that's what I was thinking. Sender encrypts bearer ecash with receivers pub key. Stacker news stores that encrypted blob. No custody issues for you as you can't get the money.
Yep, the tradeoff is you have to trust the sender/zapper not to double spend that ecash. Think that's ok in the zapping situation.
reply
0 sats \ 4 replies \ @k00b 4 Dec
Yep, the tradeoff is you have to trust the sender/zapper not to double spend that ecash.
It's not just that. The receiver also has to trust the mint to let them redeem real money and without KYC.
For Stacker, it's also important for us to be able to verify the payment is real and what the sat value is.
reply
Ah right so you need to verify the payment as that's probably used for ranking content?
How does that work when sender and receiver have connected their lightning wallets? I guess you decode the invoice but how do you know they payment was made?
reply
13 sats \ 0 replies \ @ek 4 Dec
Ah right so you need to verify the payment as that's probably used for ranking content?
Yes + take sybil fee
how do you know they payment was made?
We basically route it through our node. That’s also how we take our fee.
reply
0 sats \ 1 reply \ @k00b 4 Dec
We proxy it using hold invoices. We basically do what a lightning node does when it forwards a payment - noncustodial but they know that money actually moved and how much money moved.
reply
133 sats \ 0 replies \ @chris42 4 Dec
Ah thanks for the answers, really interesting! Keep up the good work @ek @k00b
reply