pull down to refresh
102 sats \ 18 replies \ @optimism 14 Nov \ parent \ on: Lots Of Riders Without Their Weapons meta
Getting rugged? lmao
when not rugging, custodial apps are quite pleasant
- offline receive
- receive small amounts
- no need to manage liquidity
reply
reply
Why not?
Sure, it sucks to potentially lose money, but you can limit the amount you're willing to lose for these quite nice properties though, no?
I’m not trying to advocate for custodial wallets, but I acknowledge that their UX is unmatched by any non-custodial wallet.
reply
honestly, i wouldn't mind if SN just went custodial again haha
reply
SN is a platform where you spend sats and receive interaction. It is not custodial because it is not a wallet. SN is my counterparty, not whomever I "zap", because I zap something to make it more visible.
This probably goes fully against this latest release of k00b's work and I should just shut up.
reply
reply
reply
It's a bit more complicated than that for noncustodial zaps. (As a metaphor it's fair though.)
We request an invoice from the receiver, extract the hash, then construct an invoice paid to SN's node with that same hash. Importantly, when you push money to SN's node, "paying" this invoice, we do not have the preimage to claim your payment.
To claim your payment, SN risks its own money paying the receiver to get the preimage. SN then uses this preimage to claim the money you pushed to SN.
It's an atomic split payment - part to SN, part to the receiver, and SN only gets paid if the receiver does. As far as the sats are concern, SN does what a lightning routing node does when it forwards funds.
As far as the sender can tell, they're paying SN - which is awesome because it protects the privacy/pubkey of the receiver's node/wallet. But, this also means that the sender must trust that the invoice SN serves is a wrapped invoice from the receiver.
reply
reply
SN's noncustodial zaps have worked this way since mid-2024.
The recent work just generalizes the underlying state machine. Now we handle all payments - custodial ones, JIT non-custodial payments directly to SN, JIT non-custodial zaps atomically forwarded to other stackers, etc - using the same code.
Non-custodial zaps are one of the weirdest state flows that we have, but we also have atomic refunds for some things (like territory payments). ie if you push us money, we claim the money if and only if we are able to complete the action that you're paying for. ie us settling the invoice is atomic with us mutating SN in the way that you're paying us to; otherwise, we cancel the payment and all the pending htlcs, the pending changes to the channel balances, along the route to our node are reverted as if the payment never happened.
reply
Not to be pedantic but is this really considered "atomic" or does it just try to simulate atomicity from the perspective of the user?
Not a critique of the method but rather a nerdy computer question
Then again, thinking about it more carefully, what is truly atomic anyway?
reply
reply
They have to deal with AI generated PRs. I'm sure any pain in the butt you might cause is like a tickle compared to that, haha