pull down to refresh
100 sats \ 19 replies \ @Scoresby 14 Nov \ parent \ on: Lots Of Riders Without Their Weapons meta
phoenixd as opposed to lnd or cln: comes with stupid easy liquidity management (i think maybe Zeus also does this, but I've never been clear whether I can use that with my own node).
Yes! I'm in the same boat here. Also, I want a solution I can recommend to a new user that has the user experience of custodial.
the user experience of custodial.
Getting rugged? lmao
reply
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
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