Vote for Brianoflondon's Witness KeyChain or HiveSigner Support Proposal 342 on PeakD
This is a value for value post: see the explanation in the footer.
@v4vapp is working well
v4v.app is back up and working very well with my new Lighting infrastructure following the move from Voltage. I'm now running two Lightning nodes and managing them for liquidity and payments.
When it doesn't work
Over the last couple of weeks nearly every payment has succeeded.
This was a payment my node failed to make yesterday. It was directed at a virtual Lightning wallet which are the kinds of tricks that Lightning Wallet providers do in order to have "self custody" Lightning. This sometimes works and sometimes doesn't and there's not much more I can do than just respond with a refund and say payment failed.
This is just how Lightning works (or doesn't) sometimes.
Full AI Analysis
The Lightning payment for 9758_11d553_1 failed because LND could not find a completable route to a private destination. This was not a v4vapp bug, a Hive problem, or a lack of outbound liquidity on legion.
Just to explain my setup a little: I capture very good logs in JSON format with full dumps of data structures where appropriate. These are fed into a log aggregation system which Grok's Build AI can access. I can then ask it to analyze transaction 9758_11d553_1 and it gives me something like the following.
What happened
| Invoice | lnbc1555550n… for 155,555 sat, created 00:33:59 UTC |
| Hive tx | <customer> sent 105.436 HBD to v4vapp |
| Attempt | Payment a24e6207dc… (index 11042) started 00:35:14 |
| Result | FAILED at 00:35:23 with FAILURE_REASON_NO_ROUTE, 0 sat fee |
| Refund | v4vapp sent 105.436 HBD back immediately, memo: Payment failed: FAILURE_REASON_NO_ROUTE |
The payment was in flight for 9 seconds. Successful payments that day stored a hop path (V4VAPP Hive GoPodcasting! → kappa → …). This one stayed Unknown the whole time.
Why there was no route
The invoice destination is:
02ec09fbb7b73111914a51acfbabfe8a9b7cff5b18d6349741a064adf062af9973
That node is not in the public graph (Amboss: “Node Not Found”, nothing on 1ML). It can only be reached through the invoice’s two hop hints, and both point at the same virtual/aliased private channel:
12312304x11327563x14494 — block 12,312,304 does not exist on-chain, so this is an LSP-style scid alias, not a public channel.
| Hint node | Profile |
|---|---|
025eee29468652d3a05c… |
Tor-only, 18 channels, ~2.13 BTC, no alias |
025cd6a9c52507da0a3b… |
Tor-only, 18 channels, ~2.63 BTC, no alias |
They look like twin LSP nodes: same #3399ff color, same channel count, same peers (Kraken, IBEX, allNice), onion-only. Typical hosted / mobile-wallet setup.
Required path:
legion → public graph → one of those Tor LSP nodes → private virtual channel → 02ec09fbb7
Legion had ~13.4M local sats at the time, so outbound capacity was not the problem. Those two LSP pubkeys do not appear anywhere in 30 days of Graylog, and this destination has never been paid successfully.
FAILURE_REASON_NO_ROUTE after 9 seconds, with no stored hops and 0 fee, means LND exhausted the usable paths. With a private destination and only one virtual last hop, that almost always means the last hop failed, then there was nothing else to try.
Most likely, in order:
- Destination wallet offline / not listening — the usual case for an unannounced mobile/LSP invoice.
- Private channel could not take 155,555 sat inbound (liquidity or LSP limit).
- LSP rejected the last hop (
UnknownNextPeer/TemporaryChannelFailure). Both hints are the same virtual channel, so a last-hop reject is terminal.
What this was not
- Not insufficient legion outbound liquidity
- Not an expired invoice (created 75 seconds earlier, 24h expiry)
- Not an app processing error — the fail was from LND, and the HBD refund posted cleanly
If <customer> retries, they need the receiving wallet online (or a new invoice from a wallet with public inbound). Same invoice will fail the same way if the last hop is still dead.
Value for Value
For the last few months while building @v4vapp I was generously supported by the DHF. Going forward I have a much more modest support which covers direct server costs and a little of my time.
If you appreciate the work I do on and around Hive, you can express this directly: upvoting posts on Hive is great. Also consider a direct donation (there's a Tip button on Hive or a Lightning Address) on all my posts.
Support Proposal 342 on PeakD Support Proposal 342 with Hivesigner Support Proposal 342 on Ecency Vote for Brianoflondon's Witness KeyChain or HiveSigner
