reply on: Zaps Failing, Fragility, and Bet Update \ stacker news ~meta

pull down to refresh

0 sats \ 8 replies \ @elvismercury 15 Jan \ parent \ on: Zaps Failing, Fragility, and Bet Update meta

My guess is that since the whole point of this is that SN is not the custodian, and since other people don't necessarily have a channel open to SN, that it's something to do with that leg of things. If it were just me > SN > them via direct channels it would probably be fine.

108 sats \ 7 replies \ @k00b 15 Jan

Ah, by the sounds of it your direct channel probably gets depleted of inbound sometimes, so we go through the channel you bought (which has fees unlike your direct channel).

146 sats \ 4 replies \ @elvismercury 15 Jan

I just checked logs -- here's an example.

I think this is somebody trying to zap me, right? My channel to SN has 29k inbound; my other channel has 2.4m inbound. My midwit understanding is that

a) they tried to zap me b) they don't have a channel to SN c) the route to me someplace has fees that fail

Would love to be corrected on this one.

108 sats \ 3 replies \ @k00b 15 Jan

I think this is somebody trying to zap me, right?

Yep.

My channel to SN has 29k inbound

Depending on the size of that channel, your 29k inbound might be reserved for the penalty tx and is unusable.

a) they tried to zap me

Yes.

b) they don't have a channel to SN

Actually, SN is estimating that trying to route you 21 sats with a maximum 3% fee, from SN's node, is not possible. You should see small zaps fail in this way more commonly than large zaps.

(If that 29k inbound is usable, our estimation might not be returning the lower bound wrt routing fees and this is a bug.)

c) the route to me someplace has fees that fail

Understanding how zaps on SN work might help some. They work like lnproxy does. We request an invoice from your node, then "wrap it" in an invoice to our node, then serve that to the sender. The sender pays that invoice by pushing bitcoin in its channels to SN, bitcoin that SN cannot claim that without paying your invoice first. SN then pays your invoice which allows us to claim the bitcoin the sender pushed to us.

So, for a zap to work the sender needs a route to SN with enough liquidity and the receiver needs a route from SN with enough liquidity.

It's built this way so that SN can take its sybil fee, verify that a payment actually happened, and that money actually changed hands. Importantly, SN cannot be paid unless you are paid first, and SN never has custody of the sender's money promising to give it to you. SN is doing exactly what a lightning routing node does wrt custody but in the application layer so we can couple the routed bitcoin to posts and comments. Also, by wrapping the invoice, the sender doesn't know the receiving node's pubkey - the sender only sees SN's pubkey - so we are fixing a lightning privacy issue in the process. confetti

Back to the error message. Before SN requests an invoice from your node for 21 sats (which is 70% of the 30 sat zap), we estimate if we can send you 21 sats with a maximum fee of 3% of zap amount (900 millisats). We estimate that it'll cost 1043 millisats to route you 21 sats, so we have the sender give you CCs instead of paying your node.

232 sats \ 1 reply \ @elvismercury 15 Jan

Ah, thank you, I will ruminate on this when I have mental [channel] capacity ;)

Is there an easy way to get inbound capacity to SN through my channel? Can I just send some sats to SN to prevent these types of errors?

100 sats \ 0 replies \ @k00b 15 Jan

The easiest way is to spend the outbound liquidity on something, moving it to inbound.

Can I just send some sats to SN to prevent these types of errors?

Yep. I often rebalance by zapping like mad some days, or by paying our dev bounties from my node, or buying cowboy credits for @sn.

If you use an exchange or a custodial wallet that uses lightning you can also just send sats to yourself from your node (self-custodial lightning has awesome sender privacy).

Another option is to loop out with something like loop or boltz and pay a lightning invoice that gives you the bitcoin back to an onchain address you specify.

0 sats \ 0 replies \ @k00b 15 Jan

Before SN requests an invoice from your node for 21 sats

This should say: Before SN wraps an invoice from your node for 21 sats.

30 sats \ 1 reply \ @elvismercury 15 Jan

Except the ones I notice are when my zaps to others don't go through; and then I retry later, and they do. Wouldn't that mean it's the other person's channels that are the culprit?

0 sats \ 0 replies \ @k00b 15 Jan

Wouldn't that mean it's the other person's channels that are the culprit?

Usually, yes. If you are the sender, there's a failure, and you have enough liquidity to SN's node and your sending wallet is working well, it usually indicates the receiver's wallet had a problem receiving the zap.

We have a PR for automatic retries pending review which should drastically reduce your exposure to these intermittent failures that aren't your fault.