vincenzopalazzo · May 21, 2026 12:14
diff --git a/gistfile1.txt b/gistfile1.txt
 Hypothesis (written down)

 Core Hypothesis

 The long routes (7–9 hops) that triggered the xpay "Could not create payment onion: path too long" errors on the experimental node are primarily caused by insufficient local liquidity on the Ocean ↔ Megalithic.me channel, combined with the node’s extremely limited connectivity (only two active channels).

 Detailed Reasoning

 1. Topology
   • The experimental node has only two active channels.
   • One of them is a direct channel to Megalithic.me (0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e = chan#62).
   • Megalithic.me is peered with Lexe’s main public LSP node (0314a77523d1dcbc5db56081edcbc24ab820b35e343a6c6769176de707c178d457).
   • In theory, the shortest and most natural path to most Lexe recipients should be:
     Ocean experimental → Megalithic.me → Lexe LSP (≈ 2 hops + blinded path).

 2. Observed Behavior
   • Despite the existence of this short path, askrene/getroutes frequently returned routes of 7–9 hops for payments to Lexe BOLT12 offers.
   • Even in flows that started on the Megalithic channel, the very next hop was often 035e4ff4... (Wallet of Satoshi) instead of heading toward Lexe infrastructure.
   • The short path via Megalithic was only used for smaller portions of the payments (when it was used at all). Larger parts were forced through the second, much worse channel.

 3. Liquidity Evidence
   • During at least one of the problematic Lexe payments (2026-05-20 ~08:42), the local balance on the Megalithic channel was only ≈ 2.52 million sats.
   • This limited balance explains why askrene could only push a fraction of the payment through the “good” pipe and had to route the rest the long way around.

 4. Why This Leads to the "path too long" Error
   • Long routes (many hops) leave very little room in the onion packet for large final TLVs.
   • Lexe offers already carry non-trivial TLV data (blinded paths + issuer metadata).
   • Ocean’s payout plugin adds a long payer_note (full block hash + height).
   • When these large TLVs are combined with 7–9 hop routes, xpay fails at onion creation time with code 209.

 Summary Hypothesis

 The root cause is not primarily a bug in xpay’s TLV handling, nor a problem with Lexe’s BOLT12 offers in isolation.
 It is the interaction between:

 • A very poorly connected node (only 2 channels), and
 • Limited liquidity on the single “good” channel that leads toward Lexe’s infrastructure (Megalithic).

 Because of this, askrene is frequently forced to build long routes. Those long routes then expose the known limitation in xpay when dealing with large final TLV payloads (the exact issue reported in #9156).

 Implication

 Improving local balance on the Ocean–Megalithic channel (or opening additional well-chosen channels toward Lexe’s peers) should significantly reduce the occurrence of these long routes and, consequently, the “path too long” failures — even without changes to xpay or Lexe’s offer construction.
	Hypothesis (written down)

	Core Hypothesis

	The long routes (7–9 hops) that triggered the xpay "Could not create payment onion: path too long" errors on the experimental node are primarily caused by insufficient local liquidity on the Ocean ↔ Megalithic.me channel, combined with the node’s extremely limited connectivity (only two active channels).

	Detailed Reasoning

	1. Topology
	• The experimental node has only two active channels.
	• One of them is a direct channel to Megalithic.me (0322d0e43b3d92d30ed187f4e101a9a9605c3ee5fc9721e6dac3ce3d7732fbb13e = chan#62).
	• Megalithic.me is peered with Lexe’s main public LSP node (0314a77523d1dcbc5db56081edcbc24ab820b35e343a6c6769176de707c178d457).
	• In theory, the shortest and most natural path to most Lexe recipients should be:
	Ocean experimental → Megalithic.me → Lexe LSP (≈ 2 hops + blinded path).

	2. Observed Behavior
	• Despite the existence of this short path, askrene/getroutes frequently returned routes of 7–9 hops for payments to Lexe BOLT12 offers.
	• Even in flows that started on the Megalithic channel, the very next hop was often 035e4ff4... (Wallet of Satoshi) instead of heading toward Lexe infrastructure.
	• The short path via Megalithic was only used for smaller portions of the payments (when it was used at all). Larger parts were forced through the second, much worse channel.

	3. Liquidity Evidence
	• During at least one of the problematic Lexe payments (2026-05-20 ~08:42), the local balance on the Megalithic channel was only ≈ 2.52 million sats.
	• This limited balance explains why askrene could only push a fraction of the payment through the “good” pipe and had to route the rest the long way around.

	4. Why This Leads to the "path too long" Error
	• Long routes (many hops) leave very little room in the onion packet for large final TLVs.
	• Lexe offers already carry non-trivial TLV data (blinded paths + issuer metadata).
	• Ocean’s payout plugin adds a long payer_note (full block hash + height).
	• When these large TLVs are combined with 7–9 hop routes, xpay fails at onion creation time with code 209.

	Summary Hypothesis

	The root cause is not primarily a bug in xpay’s TLV handling, nor a problem with Lexe’s BOLT12 offers in isolation.
	It is the interaction between:

	• A very poorly connected node (only 2 channels), and
	• Limited liquidity on the single “good” channel that leads toward Lexe’s infrastructure (Megalithic).

	Because of this, askrene is frequently forced to build long routes. Those long routes then expose the known limitation in xpay when dealing with large final TLV payloads (the exact issue reported in #9156).

	Implication

	Improving local balance on the Ocean–Megalithic channel (or opening additional well-chosen channels toward Lexe’s peers) should significantly reduce the occurrence of these long routes and, consequently, the “path too long” failures — even without changes to xpay or Lexe’s offer construction.
No results found