LND 0.21-beta blinded path forwarding failure with CLN BOLT12 offer

[MegalithicBTC]

Pre-Submission Checklist

• I have searched the existing issues and believe this is a new bug.
• I am not asking a question about how to use lnd, but reporting a bug (otherwise open a discussion).

LND Version

v0.21

LND Configuration

Summary

Topology:

Core Lightning payer ---publicchannel--> LND intermediary --privatechannel--> Core Lightning receiver

The BOLT12 invoice request/reply works through LND onion-message forwarding, but the actual payment HTLC fails at the LND intermediary. LND logs:

unable to decode forwarding instructions: next SCID not set for non-final blinded hop

On the CLN payer side the failure surfaces as invalid_onion_blinding, then xpay falls back to a heuristic message saying the blinded path might have insufficient capacity. The CLN route and channel balances show this is very likely not a capacity or fee-limit issue: CLN built a route sending 3010msat for a 2000msat final amount, including the LND/receiver blinded-path fee.

A control payment to an LDK/Lexe BOLT12 offer succeeds...
The successful control payment topology

Core Lightning payer ---publicchannel--> LND intermediary --other-public-channel--> LDK

In that successful case, LND is an ordinary forwarding hop toward the invoice's blinded-path first node (0314a775...), not the blinded-path first node itself. This narrows the failed case to LND acting as the first blinded-path hop/introduction node for the CLN receiver invoice.

The successful control also uses a nearly identical incoming HTLC size on the same CLN payer -> LND channel: 3003mSAT succeeds, while the failed CLN receiver attempt used 3010mSAT. That makes a simple channel reserve, HTLC minimum, or dust-sized-payment explanation unlikely.

Environment

Date of test: 2026-06-27.

Network: Bitcoin mainnet.

Payer:

• Implementation: Core Lightning
• Version/image: elementsproject/lightningd:v26.06.1
• Node id: 036cc2da86593236e0612110823b5571e26e550bcf94f4288aabd4e15d57b07b71

Intermediary:

• Implementation: LND
• Version: LND 0.21-beta
• Node id: 02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441
• Role in failed case: blinded-path first node/introduction hop, ordinary intermediary, and onion-message relay
• Route blinding/onion messages are not disabled in config; OMSG logs show onion-message forwarding succeeds.

Receiver:

• Implementation: Core Lightning
• Version/image: elementsproject/lightningd:v26.06.1
• Node id: 02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf

Channel state observed around the failure

Payer CLN <-> LND channel:

• SCID: 955579x2501x1
• Channel point: 312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1
• Capacity: 250000sat
• CLN payer had about 5000sat local from its perspective, enough for the test HTLC of 3010msat.
• LND channel policy observed for this direction/blinded payinfo:
  • base fee: 1000msat
  • proportional fee: 5000ppm
  • CLTV delta: 144

LND <-> receiver CLN channel:

• SCID: 955573x2928x1
• Channel point: 0615717b3661c996d5f03bf16b60fc1febe9f0922755378644936fe8ba2a4470:1
• Capacity: 250000sat
• Observed as private
• LND had about 249037sat local toward the receiver, enough to forward a 2 sat payment.

The important point: this was a tiny payment and both sides of the intended forwarding path appeared to have enough liquidity for it.

Reproduction commands

Commands were run from the CLN payer shell.

offer='lno1pggyxnzwyp6x2um5v4ezqmmxvejhyy8wq25ceph0xekwyf426mnhq62eg4hpwqg93y2u8jl4y7ehmg2rhv2yzqcgh0ttnv09md97w2l5awqxth780l0ejl22jr958f29zpn52cp77spq97sydcupnyvqkkluqzmnuuzeygnudpks6sw4tdhq406dtums6gp0qqe53tah42yz66j823m9fakzdf3kxvvwmmuskhrtufc7h60h5v5l6f3j535vz6p90c2rued878asm8k6gwwjyqjd832ghdrhg6ewkv9g00dsmmphkpa2ep7s9xt9km9e4uf8r9ymyyqryqfzgefnpmqgcs593dxr9yw8ht7x4gvuaaw72tmtcenhzh7zg05pwcxpwk0uh98v8nywt8jflqnyndkkc93pq2ncm6nvy7du2rkuxghj5kj37wafmcm74mja2ssh8s79uqa4se5m7'

lightning-cli --network=bitcoin decode "${offer}"
lightning-cli --network=bitcoin fetchinvoice "${offer}" 2000
lightning-cli --network=bitcoin pay '<bolt12-invoice-returned-by-fetchinvoice>'

Note: in CLN, bare 2000 means 2000msat, i.e. 2 sats. Use 2000sat for 2000 sats.

Decoded offer

{
  "type": "bolt12 offer",
  "offer_id": "02bd81434e59aaaf28d7e1756b97a1333911b1e4d38d7cd7a1249ec07a9581aa",
  "offer_description": "CLN tester offer",
  "offer_paths": [
    {
      "first_node_id": "02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441",
      "first_path_key": "0308bbd6b9b1e5db4be72bf4eb8065dfc77fdf997d4a90cb43a545106745603ef4",
      "path": [
        {
          "blinded_node_id": "02fa046e38199180b5bfc00b73e70592227c686d0d41d55b6e0abf4d5f370d202f",
          "encrypted_recipient_data": "48afb7aa882d6a47547654f6c26a6363318edef90b5c6be271ebe9f7a329fd2632a468c168257e143e65a7f1fb0d9eda439d22"
        },
        {
          "blinded_node_id": "024d3c548bb47746b2eb30a87bdb0dec37b07aac87d029965b6cb9af1271949b21",
          "encrypted_recipient_data": "0122465330ec08c42858b4c3291c7bafc6aa19cef5de52f6bc667715fc243e81760c1759fcb94ec3cc8e59e49f82649b6d6c"
        }
      ]
    }
  ],
  "offer_issuer_id": "02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf",
  "valid": true
}

Decoded BOLT12 invoice for the failed 2000msat payment

This is decoded from the exact invoice that was then passed to pay.

{
  "type": "bolt12 invoice",
  "offer_id": "02bd81434e59aaaf28d7e1756b97a1333911b1e4d38d7cd7a1249ec07a9581aa",
  "offer_description": "CLN tester offer",
  "offer_paths": [
    {
      "first_node_id": "02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441",
      "first_path_key": "0308bbd6b9b1e5db4be72bf4eb8065dfc77fdf997d4a90cb43a545106745603ef4",
      "path": [
        {
          "blinded_node_id": "02fa046e38199180b5bfc00b73e70592227c686d0d41d55b6e0abf4d5f370d202f",
          "encrypted_recipient_data": "48afb7aa882d6a47547654f6c26a6363318edef90b5c6be271ebe9f7a329fd2632a468c168257e143e65a7f1fb0d9eda439d22"
        },
        {
          "blinded_node_id": "024d3c548bb47746b2eb30a87bdb0dec37b07aac87d029965b6cb9af1271949b21",
          "encrypted_recipient_data": "0122465330ec08c42858b4c3291c7bafc6aa19cef5de52f6bc667715fc243e81760c1759fcb94ec3cc8e59e49f82649b6d6c"
        }
      ]
    }
  ],
  "offer_issuer_id": "02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf",
  "invreq_metadata": "4999894c5eefe4d93dacf9bc577b728a",
  "invreq_payer_id": "033c7a172b924e14ac22ee204545f4a1190fdbd51ce271135c6e09a7686dba6636",
  "invreq_amount_msat": 2000,
  "invreq_features": "",
  "invoice_paths": [
    {
      "first_node_id": "02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441",
      "first_path_key": "033522337b3c79da638f2d7c631466f758f4c4d73c8f8368f7da0a059dc86d198f",
      "payinfo": {
        "fee_base_msat": 1000,
        "fee_proportional_millionths": 5000,
        "cltv_expiry_delta": 162,
        "htlc_minimum_msat": 1000,
        "htlc_maximum_msat": 246153216,
        "features": ""
      },
      "path": [
        {
          "blinded_node_id": "02e0c894f415f183fa540b42fb931fcfd9fd95de996c0a05d30e78a2b359868f16",
          "encrypted_recipient_data": "19f4dea837b9000f6c9f9f4e0e7f6da60b18ddd6d33209a1dce8343b23487db6628906f6ad32ffa90197119d6a1a66187766c2eb3476c36258513ffc46404842756100c792"
        },
        {
          "blinded_node_id": "0398120da0bcd7946595894c5242edc3fa2c37dcfaf15fd9c5f7f06c7245bd3bba",
          "encrypted_recipient_data": "ab893f660a3e0becdfb443780779831b4004020da7415531a5e39cc0337247cf0e95483e6f10362b17de13504cb03e10ac11"
        }
      ]
    }
  ],
  "invoice_created_at": 1782555841,
  "invoice_relative_expiry": 7200,
  "invoice_payment_hash": "948bb8df0bee6108c5cfc8031cbf99804f9fb2db4def2e99da074a39c1a4ecc7",
  "invoice_amount_msat": 2000,
  "invoice_features": "020000",
  "invoice_node_id": "02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf",
  "signature": "d6d80bdbe1144871bc7c52032c95968959de7a651555e21b529f14f09047fa5f8e601e4edd85f61b1b319e183e5c27a086e6c864b714a705fd95e095ff14e023",
  "valid": true
}

This decoded invoice confirms:

• invoice_payment_hash is 948bb8df0bee6108c5cfc8031cbf99804f9fb2db4def2e99da074a39c1a4ecc7 for this failed payment attempt.
• invreq_amount_msat and invoice_amount_msat are both 2000.
• invoice_node_id is the receiver CLN node 02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf.
• invoice_paths[0].first_node_id is the LND intermediary 02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441.
• The invoice path payinfo is fee_base_msat=1000, fee_proportional_millionths=5000, cltv_expiry_delta=162, htlc_minimum_msat=1000, and htlc_maximum_msat=246153216.

Actual result

CLN payer output for the exact invoice above:

# getroute failed with maxparts=6, so retrying without that restriction
{
   "code": 209,
   "message": "Failed after 1 attempts. We got an error from inside the blinded path 0x0x0/1: we assume it means insufficient capacity. Then routing failed: We could not find a usable set of paths. The shortest path is 955579x2501x1->0x0x0, but 0x0x0/1 layer xpay-1 says max is 1999msat"
}

This top-level pay result is consistent with the LND-side blinded-forwarding failure below. The "insufficient capacity" part looks like a CLN/xpay interpretation of a blinded-path error, not the original failure; earlier detailed CLN debug from the same offer/path showed plugin-cln-xpay receiving invalid_onion_blinding before applying that heuristic.

Expected result

LND should decode the blinded forwarding instructions and forward the payment to the receiver CLN over the LND <-> receiver channel, or return a more specific protocol error if the incoming blinded payload is malformed.

Key evidence

1. Onion-message relay succeeds

The LND intermediary forwards the BOLT12 invoice request/reply onion messages. This means the offer/invoice-fetch stage is working before the payment HTLC fails:

2026-06-27 10:24:01.408 [DBG] OMSG: OnionPeerActor received OnionMessage peer=036cc2da86593236e0612110823b5571e26e550bcf94f4288aabd4e15d57b07b71 path_key=0308bbd6b9b1 onion_blob=00023d067495ffb8a234 blob_length=1366
2026-06-27 10:24:01.426 [DBG] OMSG: Forwarding onion message peer=036cc2da86593236e0612110823b5571e26e550bcf94f4288aabd4e15d57b07b71 path_key=0308bbd6b9b1 next_node_id=02a78dea6c27
2026-06-27 10:24:01.485 [DBG] OMSG: OnionPeerActor received OnionMessage peer=02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf path_key=023f22a098af onion_blob=00031889fd9c386b2224 blob_length=1366
2026-06-27 10:24:01.498 [DBG] OMSG: Forwarding onion message peer=02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf path_key=023f22a098af next_node_id=036cc2da8659

2. CLN builds a route through LND and includes the fee

CLN sees the invoice blinded route as LND introduction node to a blinded terminal node:

lightningd-payer-1 | 2026-06-27T09:54:17.515Z DEBUG plugin-cln-xpay: Invoice gave route 02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441->020000000000000000000000000000000000000000000000000000000000000001 (0x0x0/1)

For a 2000msat final amount, CLN constructs a route that sends 3010msat into LND:

lightningd-payer-1 | 2026-06-27T09:54:17.550Z DEBUG plugin-cln-askrene: Flow 0/1: 3010msat/162 955579x2501x1/1 -> 3010msat/162 0x0x0/1 -> 2000msat/0 (prob=99.717%)

That 3010msat is consistent with a 2000msat final amount plus 1000msat base fee plus 5000ppm on 2000msat (10msat). So this does not look like CLN refusing to pay the base fee.

Expanded route JSON from CLN:

{
  "probability_ppm": 997171,
  "routes": [
    {
      "probability_ppm": 997171,
      "amount_msat": 2000,
      "final_cltv": 0,
      "path": [
        {
          "short_channel_id_dir": "955579x2501x1/1",
          "node_id_in": "036cc2da86593236e0612110823b5571e26e550bcf94f4288aabd4e15d57b07b71",
          "node_id_out": "02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441",
          "amount_in_msat": 3010,
          "amount_out_msat": 3010,
          "cltv_in": 162,
          "cltv_out": 162,
          "next_node_id": "02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441",
          "amount_msat": 3010,
          "delay": 162
        },
        {
          "short_channel_id_dir": "0x0x0/1",
          "node_id_in": "02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441",
          "node_id_out": "020000000000000000000000000000000000000000000000000000000000000001",
          "amount_in_msat": 3010,
          "amount_out_msat": 2000,
          "cltv_in": 162,
          "cltv_out": 0,
          "next_node_id": "020000000000000000000000000000000000000000000000000000000000000001",
          "amount_msat": 3010,
          "delay": 162
        }
      ]
    }
  ]
}

3. CLN sends the HTLC to LND

lightningd-payer-1 | 2026-06-27T09:54:17.551Z DEBUG lightningd: injectpaymentonion: sending to channel 955579x2501x1
lightningd-payer-1 | 2026-06-27T09:54:17.571Z DEBUG 02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441-channeld-chan#1: Adding HTLC 4 amount=3010msat cltv=955800 gave CHANNEL_ERR_ADD_OK
lightningd-payer-1 | 2026-06-27T09:54:17.571Z DEBUG 02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441-channeld-chan#1: peer_out WIRE_UPDATE_ADD_HTLC

4. LND receives the matching HTLC, then fails while decoding the blinded forwarding instructions

These LND logs match the exact failed invoice above: payment hash 948bb8df0bee6108c5cfc8031cbf99804f9fb2db4def2e99da074a39c1a4ecc7.

2026-06-27 10:24:01.729 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): receiveupstream msg UpdateAddHTLC, handling now...
2026-06-27 10:24:01.729 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): receiveupstream htlc with payment hash(948bb8df0bee6108c5cfc8031cbf99804f9fb2db4def2e99da074a39c1a4ecc7), assigning index: 5
2026-06-27 10:24:01.729 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): handledupstream msg UpdateAddHTLC
2026-06-27 10:24:01.749 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): receiveupstream msg CommitSig, handling now...
2026-06-27 10:24:01.814 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): receiveupstream msg RevokeAndAck, handling now...
2026-06-27 10:24:01.824 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): processing 1 remote adds for height 16
2026-06-27 10:24:01.861 [DBG] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): Introduction blinded node switching out failure error: 5
2026-06-27 10:24:01.861 [TRC] HSWC: Notifying link failure event: forward over (Chan ID=955579:2501:1, HTLC ID=5), incoming amount: 3010 mSAT, incoming timelock: 955802
2026-06-27 10:24:01.861 [ERR] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): unable to decode forwarding instructions: next SCID not set for non-final blinded hop
2026-06-27 10:24:01.867 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): fwd package has no settle/fails to process exiting early
2026-06-27 10:24:01.960 [TRC] HSWC: Notifying final settle event: (Chan ID=955579:2501:1, HTLC ID=5)

5. CLN pay result for the same invoice

The matching CLN-side payment attempt exits with status 1 and returns code 209:

# getroute failed with maxparts=6, so retrying without that restriction
{
   "code": 209,
   "message": "Failed after 1 attempts. We got an error from inside the blinded path 0x0x0/1: we assume it means insufficient capacity. Then routing failed: We could not find a usable set of paths. The shortest path is 955579x2501x1->0x0x0, but 0x0x0/1 layer xpay-1 says max is 1999msat"
}

Earlier detailed CLN debug logs from the same offer/path showed plugin-cln-xpay receiving invalid_onion_blinding from LND before applying the blinded-path capacity heuristic. The matching LND logs above show LND generated the failure while trying to decode the blinded forwarding instructions.

Control case: LDK receiver succeeds

A separate BOLT12 offer payment to an LDK/Lexe receiver succeeded from the same CLN payer, through the same CLN payer -> LND channel. This shows ordinary forwarding from the CLN payer through LND works for a BOLT12 invoice with a blinded path.

Key CLN-side result:

invoice_payment_hash: 339966647736fab66251ff6880a647b8dbbb0a41689fb957296572c3f0f29d6e
invoice_amount_msat: 2000
invoice_node_id: 02ff785b83610b75f1e4ec20dc90a5ee6c105e5c164ce50a41dc034fe49940c79f
pay_status: complete
amount_sent_msat: 3003
parts: 2

Decoded invoice path for the LDK receiver:

offer_issuer: ₿blooming-barbet@lexe.app
offer_issuer_id / invoice_node_id: 02ff785b83610b75f1e4ec20dc90a5ee6c105e5c164ce50a41dc034fe49940c79f
invoice_paths[0].first_node_id: 0314a77523d1dcbc5db56081edcbc24ab820b35e343a6c6769176de707c178d457
invoice_paths[0].payinfo.fee_base_msat: 0
invoice_paths[0].payinfo.fee_proportional_millionths: 0
invoice_paths[0].payinfo.cltv_expiry_delta: 114

The important distinction is that in this successful LDK case, the invoice's blinded-path first node is 0314a775..., not the LND intermediary 02a98c86.... The CLN payer routes publicly through LND and other hops toward 0314a775..., then enters the blinded path. In the failing CLN receiver case, the invoice's blinded-path first node is the LND intermediary itself (02a98c86...), and LND fails while decoding the blinded forwarding instructions.

Matching LND logs for the successful LDK payment show normal forwarding and settlement, not blinded decoding failure:

2026-06-27 10:45:56.371 [TRC] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): receiveupstream htlc with payment hash(339966647736fab66251ff6880a647b8dbbb0a41689fb957296572c3f0f29d6e), assigning index: 12
2026-06-27 10:45:56.505 [DBG] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): forwarding 1 packets to switch: reforward=false
2026-06-27 10:45:56.512 [TRC] HSWC: Checking for circular route: incoming=955579:2501:1, outgoing=870574:2614:1 (payment hash: 339966647736fab66251ff6880a647b8dbbb0a41689fb957296572c3f0f29d6e)
2026-06-27 10:45:56.512 [TRC] HSWC: Notifying forward event: forward over (Chan ID=955579:2501:1, HTLC ID=12) -> (Chan ID=870574:2614:1, HTLC ID=33272), incoming amount: 3003 mSAT, incoming timelock: 956581, outgoing amount: 2001 mSAT, outgoing timelock: 956437
2026-06-27 10:46:02.939 [DBG] HSWC: Closed completed SETTLE circuit for 339966647736fab66251ff6880a647b8dbbb0a41689fb957296572c3f0f29d6e: (955579:2501:1, 12) <-> (870574:2614:1, 33272)
2026-06-27 10:46:02.939 [INF] HSWC: Forwarded HTLC(339966647736fab66251ff6880a647b8dbbb0a41689fb957296572c3f0f29d6e) of 2001mSAT (fee: 1002 mSAT) from IncomingChanID(955579:2501:1) to OutgoingChanID(870574:2614:1)
2026-06-27 10:46:03.038 [TRC] HSWC: Notifying final settle event: (Chan ID=955579:2501:1, HTLC ID=12)

No unable to decode forwarding instructions, next SCID not set, Introduction blinded node switching out failure, or Notifying link failure event appears for this successful LDK payment.

This is also a direct channel-reserve control: LND accepted and settled an incoming 3003mSAT HTLC on the same incoming channel (955579:2501:1) only about 22 minutes after the failed 3010mSAT HTLC on that channel.

Interpretation

The failure appears to be on the LND intermediary while processing the incoming payment HTLC:

next SCID not set for non-final blinded hop

This looks like a blinded-payment forwarding/decode issue rather than:

• a BOLT12 offer/invoice request issue, because onion messages were forwarded and an invoice was returned;
• a fee-limit issue, because CLN sent 3010msat for a 2000msat final amount, matching the observed 1000msat + 5000ppm fee;
• a simple liquidity/reserve issue, because the intended channels had enough balance for a 2 sat test payment and the LDK/Lexe control settled a nearly identical 3003mSAT incoming HTLC on the same incoming channel;
• a generic inability for this CLN payer to pay BOLT12/blinded invoices through this LND node, because the LDK/Lexe control payment succeeds through the same CLN payer -> LND channel.

The observed behavior is consistent with: LND 0.21-beta fails when it is the first blinded-path hop/introduction node for this CLN receiver invoice. In the successful LDK/Lexe control, LND is only a normal forwarding hop toward the invoice's blinded-path first node, and it settles correctly.

The CLN xpay message saying "we assume it means insufficient capacity" appears to be a fallback interpretation of the blinded-path failure; earlier detailed CLN logs from the same offer/path showed invalid_onion_blinding before this heuristic.

Backend Version

Bitcoin Core 29.3

Backend Configuration

nothing speical

OS/Distribution

image: lightninglabs/lnd:v0.21.0-beta

Bug Details & Steps to Reproduce

see issue

Expected Behavior

see issue

Debug Information

No response

Environment

No response

[ziggie1984]

Thanks for the detailed report. Based on the logs and the decoded invoice, this looks like a valid LND forwarding interop issue.

The failure is happening while LND is acting as a non-final node in the blinded payment path:

CLN payer -> LND introduction/forwarding node -> CLN receiver

Per BOLT 04, encrypted_data_tlv for each non-final blinded payment node may contain exactly one of short_channel_id or next_node_id. LND currently appears to support the short_channel_id form for ordinary blinded payment forwarding, but not the general next_node_id form.

[MegalithicBTC]

Thanks, let me know if I can be useful on my end, more logs or etc.

[gijswijs]

So the onion message forwarding seems to work. The BOLT12 Invoice request and reply are transferred through the LND node just fine. But the HTLC fails on the blinded path. The error from the LND node is telling:

2026-06-27 10:24:01.861 [TRC] HSWC: Notifying link failure event: forward over (Chan ID=955579:2501:1, HTLC ID=5), incoming amount: 3010 mSAT, incoming timelock: 955802
2026-06-27 10:24:01.861 [ERR] HSWC: ChannelLink(312f4781ae09ac68052377e83548ae4da118919085ff4e85c0bb8dd6e2e75c1d:1): unable to decode forwarding instructions: next SCID not set for non-final blinded hop

@MegalithicBTC Are we sure that the blinded path provided in the offer contains a SCID? Onion messages are allowed to be routed based on Node IDs but HTLCs are routed over channels.

[MegalithicBTC]

I did another pass specifically to answer whether the blinded payment path generated by the CLN receiver contains a SCID for the LND introduction hop.

A normal decode of the BOLT12 offer/invoice cannot answer that, because short_channel_id vs next_node_id is inside encrypted_recipient_data. So I instrumented the CLN receiver before that data is encrypted.

What I changed:

• Receiver implementation: Core Lightning elementsproject/lightningd:v26.06.1
• Instrumented file/function: CLN offers plugin, plugins/offers_invreq_hook.c, inside found_best_peer
• Instrumentation point: after CLN calls new_encdata_tlvs(...) and before it calls blinded_path_from_encdata_tlvs(...)
• Logged fields:
  • selected peer / receiver node id
  • configured SCIDs passed into new_encdata_tlvs
  • per-hop plaintext tlv_short_channel_id
  • per-hop plaintext tlv_next_node_id
  • payment relay / constraints / path_id status

I then created a fresh BOLT12 offer on the CLN receiver and fetched a fresh invoice from the CLN payer. I did not need to attempt payment for this part, because the question was about the receiver-created plaintext TLV before encryption.

Fresh decoded invoice fields:

invoice_payment_hash: 408cf3efad48e94143be9da93828b2bcf033d7f1868e5854c3378526d782a337
invoice_amount_msat: 2000
invoice_node_id: 02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf
invoice_paths[0].first_node_id: 02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441
fee_base_msat: 1000
fee_proportional_millionths: 5000
cltv_expiry_delta: 162

Receiver-side plaintext TLV logs for that exact invoice_payment_hash:

CLN_BPATH_DEBUG invoice_payment_hash=408cf3efad48e94143be9da93828b2bcf033d7f1868e5854c3378526d782a337 selected_peer=02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441 receiver=02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf configured_scids[0]=none configured_scids[1]=none selected_capacity=55753048064msat selected_htlc_min=1000msat selected_htlc_max=245235712msat selected_fee_base_msat=1000 selected_fee_ppm=5000 selected_cltv_delta=144

CLN_BPATH_DEBUG invoice_payment_hash=408cf3efad48e94143be9da93828b2bcf033d7f1868e5854c3378526d782a337 hop=0 node=02a98c86ef366ce226aad6e7706959456e1701058915c3cbf527b37da143bb1441 tlv_short_channel_id=none tlv_next_node_id=02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf payment_relay=set fee_base_msat=1000 fee_ppm=5000 cltv_delta=144 payment_constraints=set htlc_minimum_msat=1000 max_cltv_expiry=957140 path_id=none

CLN_BPATH_DEBUG invoice_payment_hash=408cf3efad48e94143be9da93828b2bcf033d7f1868e5854c3378526d782a337 hop=1 node=02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf tlv_short_channel_id=none tlv_next_node_id=none payment_relay=none payment_constraints=none path_id=present(len=32)

So the direct answer is: no, the CLN receiver is not putting a SCID in hop 0. For the non-final hop decrypted by the LND introduction node, CLN sets:

tlv_short_channel_id=none
tlv_next_node_id=02a78dea6c279bc50edc322f2a5a51f3ba9de37eaee5d542173c3c5e03b58669bf

My current read of BOLT 4 is that this is allowed: the creator of encrypted_recipient_data must include exactly one of encrypted_data_tlv.short_channel_id or encrypted_data_tlv.next_node_id for each non-final node. In this case CLN includes exactly one, next_node_id.

So this now looks less like "does the CLN blinded path contain a SCID?" and more like "does LND 0.21-beta reject the spec-allowed next_node_id form when it is the first blinded-path/introduction node?"

That also lines up with the LND-side error:

unable to decode forwarding instructions: next SCID not set for non-final blinded hop

The receiver-side instrumentation shows there is no next SCID, but there is a next node id.

Spec reference: BOLT #4 encrypted_recipient_data requirements: https://github.com/lightning/bolts/blob/master/04-onion-routing.md#inside-encrypted_recipient_data-encrypted_data_tlv

[gijswijs]

We confirmed and it's indeed the case that LND 0.21-beta rejects the spec-allowed next_node_id form when used for HTLCs. (It is supported for onion messages)

btw, thank you for the thorough investigation. Helps a ton.