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

pull down to refresh

278 sats \ 18 replies \ @SimpleStacker 15 Jan \ parent \ on: Zaps Failing, Fragility, and Bet Update meta

The only time my zaps fail is when I have a problem on my end. Usually lost internet connection or my computer that runs my wallet restarted.

I highly recommend everyone who wants to use Stacker News with an attached wallet to use a self-custodial lightning wallet with a direct channel. You will not pay any routing fees and you will have a consistent, reliable experience.

153 sats \ 6 replies \ @SimpleStacker 15 Jan

I highly recommend everyone who wants to use Stacker News with an attached wallet to use a self-custodial lightning wallet with a direct channel. You will not pay any routing fees and you will have a consistent, reliable experience.

I may have spoken too soon, lol.

Last night my computer restarted and when I reopened Alby, I reopened the wallet, but the NWC connection to SN couldn't get re-established. I ultimately had to delete the old NWC connection and start a new one.

I'm curious as to why that might be. The wallet logs didn't show any routing errors or anything, just timeouts on sending/receiving payments.

100 sats \ 5 replies \ @k00b 15 Jan

I've noticed after prior updates to Alby Hub my NWC strings are all invalidated. I think it might be a symptom of Alby Hub being kind of new and them correcting mistakes they made with our older NWC strings when we update. I hope this won't always be the case.

I'm curious as to why that might be. The wallet logs didn't show any routing errors or anything, just timeouts on sending/receiving payments.

NWC strings are doing two things:

giving us permission to do stuff on your node
telling us how to communicate with your node to do that permitted stuff

So, when an NWC string goes bad, it either has to do with those permissions going bad, ie being revoked or expiring, or the way we've been instructed to communicate with your node changing or not working.

Routing and fees are in another layer, let's call it The Lightning Layer, and The NWC Layer sits on top of it doing the things I mentioned above. If The NWC Layer goes bad, it means we can't communicate with The Lightning Layer, and the only indication we have that that's happening is The NWC Layer ignores us and we timeout.

176 sats \ 4 replies \ @SimpleStacker 15 Jan

Ok, then I'm reasonably sure the error was related to NWC strings and not Lightning.

What I don't quite understand is that the wallet was working right up til last night. My computer restarted after I went to bed, and it wasn't working after restarting the wallet in the morning. It started working again after I downloaded the new Alby update, deleting my old NWC ones, and making new ones.

30 sats \ 3 replies \ @k00b 15 Jan

Restarting must have invalidate the NWC strings on Alby Hub's end.

The NWC connection isn't persistent or anything, so it wouldn't affect our end. On our end, if you give us an NWC string, whether good or bad, all we can do is sign messages with it and publish them to the relay specified then wait for responses.

Timeouts usually happen when responses don't come back, and responses don't come back when Alby considers the NWC string invalid afaik.

0 sats \ 2 replies \ @SimpleStacker 15 Jan

So I guess I'm wondering if/where/when an Alby server sits between my computer and Stacker News?

Because I was running the same version of the Alby software on my computer as the night before, with the same NWC strings that failed in the morning. That shouldn't happen unless restarting somehow changed something on an Alby server somewhere, right?

Edit: Sorry, I know this is probably more a question for Alby. But I'm not really sure how NWC works, so this is all educational to me.

500 sats \ 1 reply \ @k00b 15 Jan

Hmm I'm sure Alby has an explainer somewhere on how NWC works, but here's mine:

Basically, Alby runs a nostr relay - a server with a public ip and a generic API for sending and receiving messages.
When your Hub creates an NWC string, they generate a private key and associate it with the permissions to your lightning node that you specify.
Your NWC string gives SN, or anyone you give the NWC string to, this private key.
Hub listens for encrypted notes sent to Alby's relay where this public/private key is the recipient.
If SN wants an invoice from you, it sends a message signed/encrypted with this private key to alby's relay, then listens for the result.
Your hub, listening, sees the message, and checks if the bearer of that private key has permission to do the requested action.
If it does, Hub performs the requested action, encrypts the result, then sends it to Alby's relay.
SN, listening, now has the invoice it requested.

That shouldn't happen unless restarting somehow changed something on an Alby server somewhere, right?

Restarting more likely changed something on your computer, but it shouldn't have absent a bug or some reason only alby would know. I can't make sense of it.

139 sats \ 0 replies \ @SimpleStacker 15 Jan

Interesting. Thanks for the explainer. Yes, I wonder if restarting affected my computer's communication with Alby's nostr relay somehow. That seems to be the most likely culprit.

30 sats \ 10 replies \ @elvismercury 15 Jan

I have a channel to SN and some inbound I bought from @Rizful (link) which I recommend for learning tons about using / managing an LN node, either their cloud one or their awesome tutorial on setting up your own LND w/ Docker.

27 sats \ 9 replies \ @SimpleStacker 15 Jan

Curious as to why you'd get routing fee errors then, if you have a direct channel.

0 sats \ 8 replies \ @elvismercury 15 Jan

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.

reply on another page

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.