pull down to refresh
100 sats \ 17 replies \ @Scoresby 14 Nov \ parent \ on: Lots Of Riders Without Their Weapons meta
when not rugging, custodial apps are quite pleasant
- offline receive
- receive small amounts
- no need to manage liquidity
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
It depends on what you mean by atomic, but fwiw I don't mean to use the term lightly.
The lightning forward is what I'd call game theoretically atomic. We cannot claim the sender's money without paying the receiver, and once we've paid the receiver we certainly want to claim the sender's money. If we are unable to (or simply don't) claim the sender's money, the incoming payment becomes "delinquent" and the channel the payment is on will be force closed.
As for atomic refunds, we settle the incoming invoice within the database transaction that mutates SN. If the mutation fails before we settle the invoice, we cancel the payment without claiming it and the upstream channel balances revert. Even if there's some kind of mistake after the invoice is settled, SN's state machine can flow in only one direction: toward successfully completing the mutation. Even if errors/mistakes continue SN will try to complete the mutation indefinitely until it succeeds.
Perhaps one should claim that all of this is relatively atomic, but as far as computers are concerned, anything but a bit flip is relatively atomic.