pull down to refresh

Lnproxy wouldn’t have initiated the payment to you if Strike didn’t pay the wrapped invoice, so assuming you saw evidence of a payment in Phoenix, we can rule out strike. It’s unclear from your post how long the payment was stuck, but lnproxy (if it didn’t experience an unexpected problem which given the code I read 6 months ago would cause it to exit and required manual recovery) would’ve released the held payment once it knew the payment failed. It’s possible that ACINQ was holding the payment from lnproxy, trying to splice in liquidity to your channel and that took awhile to fail.
Wait, what did you read about lnproxy? I am interested in something like that - and am looking for more information about it.
It's an old post, but there is a lot of great information archived here on SN. Thanks!!!
reply
0 sats \ 2 replies \ @k00b 3 Feb
https://lnproxy.org … go to the GitHub … every zap here works just like lnproxy btw. If you enable the proxy in your settings, every deposit to sn or payment to your sn Lightning address is proxied.
reply
cool, i saw that in the settings. the more i learn about lightning, the more important something like lnproxy seems. we need lnproxy (or something similar) by default throughout lightning imo.
reply
100 sats \ 0 replies \ @k00b 3 Feb
Bolt12 does that with a feature called blinded paths.
reply