reply on: Lots Of Riders Without Their Weapons \ stacker news ~meta

pull down to refresh

100 sats \ 8 replies \ @SimpleStacker 5h \ parent \ on: Lots Of Riders Without Their Weapons meta

honestly, i wouldn't mind if SN just went custodial again haha

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.

100 sats \ 6 replies \ @Scoresby 4h

this aligns with Darth's slogan: pay to post.

But it's not as simple as SN is the counterparty. You pay the territory owner (who pays SN) and SN.

Also you might pay (zap) the post or comment creator to encourage them to write more of such things.

102 sats \ 5 replies \ @optimism 4h

No. I pay SN (check your lightning invoices)

SN just has a very generous revenue share agreement with posters, territory "owners" (sponsors) and the rewards pool.

(but like I said i should shut up so I'm not going further lol)

100 sats \ 2 replies \ @Scoresby 4h

I am very sucky at reading LN invoices, but my mental model of this was that SN wrapped the invoice a little like Phoenix's LSP does for payments to Phoenix users. I'll check on this independently (respecting your reluctance to go further).

102 sats \ 1 reply \ @optimism 4h

Thanks, I just don't want to be a pain in the butt to the SN team.

0 sats \ 0 replies \ @SimpleStacker 3h

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

0 sats \ 1 reply \ @k00b 15m

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.

0 sats \ 0 replies \ @k00b 1m

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.