😅

Speaking of routing fees, they wont show up in `lncli feereport` but you can copy paste the payment hashes from the logs to a script like this to see how much you made:

```

lnproxy$ cat ./proxyfee

#!/bin/sh

{

lncli trackpayment --json $1 | jq -r '(.value_msat | tonumber) + (.fee_msat | tonumber)'

lncli lookupinvoice $1 | jq -r '.amt_paid_msat'

} |

awk '

NR == 1 {paid=$1 ; printf "paid: %0.0f\n", $1/1000}

NR == 2 {got=$1 ; printf " got: %0.0f\n", $1/1000}

END {printf "diff: %0.0f\n", (got - paid)/1000}

'

```

Run with `./proxyfee `

Disclaimer: lnproxy.org now defaults to selecting a random relay from the centralized list you can find on github (one day we will query nostr for relay ads).

It's good time to post "running lnproxy-relay" and start collecting some some routing fees.

An anon contributor helped me with some updates to the frontend at lnproxy.org.

The idea is that we want to foster an eco-system with multiple relays, so now the page shows the relay you're connectiong to more prominently. The default is still set to the realy hosted at lnproxy.org but it's much easier now to pick an alternative relay.

I'd like to eventually move to the cashu-mint-style model of fetching relays from announcements published to nostr, but since the current front end has been up for years with a couple real uses, I don't want to change the trust model until that's ready. It will add some friction to the UI, you'll be forced to pick a relay before wrapping an invoice, but it will be worth it to improve decentralization.

🫂

Always could use more. How much for a 0.05 bitcoin channel?

OK, I guess I'll go with old reliable lnbig

pretty based that they still have a banner for adopting bitcoin 2021 on their site

nostr:nevent1qqsqqqqpga78xl6sjk28yuz7lhzya5ky5u6znhzxr3g79q0eqh0566gpr9mhxue69uhkcctzda6hytnxd9shg6npvchxxmmd9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshsz9thwden5te0dehhxarj9ehhsarj9ejx2a305jxt29

Node is finally back up, who wants to sell me some inbound

simplex, just saw your message 🤝

Part of this was a known issue with LND (your intuition was spot-on nostr:npub186tqtnx8nc502veqkguypvzpm5hq53p69qrl8l0hes9c4k8mzrssfk59su)

If you want to see which inflight payments are actually stuck you can do something like this:

lncli listpayments --include_incomplete |

jq -r '

.payments |

.[]

| select(.status == "IN_FLIGHT") |

[.payment_hash, .value_msat, ([.htlcs | .[] | select(.status == "IN_FLIGHT") | .route.total_time_lock ] | max)] |

@tsv

'

Then check that the max route.total_time_lock is in the future

Issue resolved, back to normal

nostr:nevent1qqsqqqqpms0nzjzk9gg4g5rxhk3axhrgkerdkkg3nau22udltzhftxqpr9mhxue69uhkcctzda6hytnxd9shg6npvchxxmmd9uq32amnwvaz7tmwdaehgu3wdau8gu3wv3jhvtcpzemhxue69uhkummnw3ex2mrfw3jhxtn0wfnj7myhlj9

hard to say..

could evenbe the destination holding up my liquidity

ty

If it's because your node is down it's not really a stuck payment

Stuck payments are caused by other nodes in the route, so not relevant but, LND.

Is anyone else getting more stuck payments on the lightning network recently?

Yes, spinning up new nodes for privacy is a very good option. Better in lots of ways. But requires onchain transactions so could get expensive.

Nothing has 100% success on lightning 😅

But your point is very good. Adding an lnproxy shunt to your route will decrease the success rate significantly. But you just need to keep trying / play with the routing fees and it will work eventually. Plus, no custodial risk.

Exactly

that doesn't matter. you can give lnproxy a blinded invoice, that it can parse and lnproxy will give you an unblinded bolt11 invoice