blinded paths: max_cltv_expiry less than current block height

[carlaKC]

Issue and Steps to Reproduce

I've been testing out blinded payments w/LND and ran into an issue with max_cltv_expiry being set to 108 when the current block height is 300.

Steps to reproduce:

• CLN version: lightningd: v24.02.1-11-gdf0f4c4
• Setup a private channel with a CL node: LND --(private channel)-- CL0
• Create an offer, fetch an invoice for it and try to pay it
• Observe that the max_cltv_expiry value is less than current block height

The private channel that I opened has LND's defaults - 80 CLTV delta and 1 msat HTLC minimum.

Command Output

Create offer on CL0:

cl0 offer 1000 "test1"
{
   "offer_id": "85be3c42fd0a3edf0dddabf0e89eaa8155078dfa5b8191f5cf18794e53151170",
   "active": true,
   "single_use": false,
   "bolt12": "lno1qgsqvgnwgcg35z6ee2h3yczraddm72xrfua9uve2rlrm9deu7xyfzrcgqgp7szs9w3jhxap3zcssyvx6j4z79ue9ap435tzfev5kgwualnzvz24cayewqw96wgary0qc",
   "used": false,
   "created": true
}

Fetch an invoice for the offer (using another CL node that's just connected on P2P):

cl1 fetchinvoice lno1qgsqvgnwgcg35z6ee2h3yczraddm72xrfua9uve2rlrm9deu7xyfzrcgqgp7szs9w3jhxap3zcssyvx6j4z79ue9ap435tzfev5kgwualnzvz24cayewqw96wgary0qc
{
   "invoice": "lni1qqgdktfjcxeny5s3d52e23dzr282cq3qqc3xu3s3rg94nj40zfsy866mhu5vxne6tcej5878k2mneuvgjy8ssqsraq9q2ar9wd6rz93pqgcd4929utejt6rtrgkynjefvsaemlxycy4t36fjuqut5u36xg7ps5pqqc3xu3s3rg94nj40zfsy866mhu5vxne6tcej5878k2mneuvgjy84sggrk95tey5r8y2q0xlpjjrm0pd9z5y7dqtaafc35jll882pqjmfc236peczh6vpaq6yyuay27pp2pd7q2murd4q3fv9pnjd0zc6fsz4scu9fnys935u7mvgxvv7wcpw5dcm82vnu9ngnrysr2udear4qz4j27r7yf8dqgp4z2qgk2fn7yzq4tqwul76hrm65z989v852jejxehtzehm2nq9g6qq93l6kntufmmmrln0cp32pffxsy87zthxzkls0g086yjnlr8yaz84pntvqwyeetwf54gscq9pqtprg8596n8r6ce9tt6xmvtedlx69g5zpc9shky9p00emchd37sz2qpjw2vv5h64795m9kj5jh506chmrkrtcah3tkeht4vnflftq0ukq0je8qt8waclxj670v9tna9dqx8mf0xm5gwqqqqraqqqqqqpqpgqqqqqqqqqqqlgqqqqqqpewqqqqqqq5szxt7ye725zpgd6tetjnyl2azpu3z0rk52hks96vhqkp4a0uf59z2g7dufzy08y4gpq869syyprpk54gh30xf0gdvdzcjwt99jrh80ucnqj4w8fxtsr3wnj8gercx8sgpl3kqv24vm779a8uqr8knvlz9c3egje4lmfrd3ecpgddypgkasnvj9le64hhytflvumkr7e2suhhty2ktndnxks49z4hednrfrnfzlr",
   "changes": {}
}

Decode the invoice to grab info to make payment from LND:

cl0 decode lni1qqgdktfjcxeny5s3d52e23dzr282cq3qqc3xu3s3rg94nj40zfsy866mhu5vxne6tcej5878k2mneuvgjy8ssqsraq9q2ar9wd6rz93pqgcd4929utejt6rtrgkynjefvsaemlxycy4t36fjuqut5u36xg7ps5pqqc3xu3s3rg94nj40zfsy866mhu5vxne6tcej5878k2mneuvgjy84sggrk95tey5r8y2q0xlpjjrm0pd9z5y7dqtaafc35jll882pqjmfc236peczh6vpaq6yyuay27pp2pd7q2murd4q3fv9pnjd0zc6fsz4scu9fnys935u7mvgxvv7wcpw5dcm82vnu9ngnrysr2udear4qz4j27r7yf8dqgp4z2qgk2fn7yzq4tqwul76hrm65z989v852jejxehtzehm2nq9g6qq93l6kntufmmmrln0cp32pffxsy87zthxzkls0g086yjnlr8yaz84pntvqwyeetwf54gscq9pqtprg8596n8r6ce9tt6xmvtedlx69g5zpc9shky9p00emchd37sz2qpjw2vv5h64795m9kj5jh506chmrkrtcah3tkeht4vnflftq0ukq0je8qt8waclxj670v9tna9dqx8mf0xm5gwqqqqraqqqqqqpqpgqqqqqqqqqqqlgqqqqqqpewqqqqqqq5szxt7ye725zpgd6tetjnyl2azpu3z0rk52hks96vhqkp4a0uf59z2g7dufzy08y4gpq869syyprpk54gh30xf0gdvdzcjwt99jrh80ucnqj4w8fxtsr3wnj8gercx8sgpl3kqv24vm779a8uqr8knvlz9c3egje4lmfrd3ecpgddypgkasnvj9le64hhytflvumkr7e2suhhty2ktndnxks49z4hednrfrnfzlr
{
   "type": "bolt12 invoice",
   "offer_id": "85be3c42fd0a3edf0dddabf0e89eaa8155078dfa5b8191f5cf18794e53151170",
   "offer_chains": [
      "06226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f"
   ],
   "offer_amount_msat": 1000,
   "offer_description": "test1",
   "offer_node_id": "0230da9545e2f325e86b1a2c49cb29643b9dfcc4c12ab8e932e038ba723a323c18",
   "invreq_metadata": "db2d32c1b33252116d159545a21a8eac",
   "invreq_payer_id": "03b168bc92833914079be19487b785a51509e6817dea711a4bff39d4104b69c2a3",
   "invreq_chain": "06226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f",
   "invoice_paths": [
      {
         "first_node_id": "02be981e8344273a457821505be02b7c1b6a08a5850ce4d78b1a4c055863854cc9",
         "blinding": "02c69cf6d883319e7602ea371b3a993e166898c901ab8dcf47500ab25787e224ed",
         "payinfo": {
            "fee_base_msat": 1000,
            "fee_proportional_millionths": 1,
            "cltv_expiry_delta": 80,
            "features": ""
         },
         "path": [
            {
               "blinded_node_id": "03512808b2933f1040aac0ee7fdab8f7aa08a72b0f454b32366eb166fb54c05468",
               "encrypted_recipient_data": "7fab4d7c4ef7b1fe6fc062a0a526810fe12ee615bf07a1e7d1253f8ce4e88f50cd6c03899cadc9a5510c00a1"
            },
            {
               "blinded_node_id": "02c2341e85d4ce3d63255af46db1796fcda2a2820e0b0bd8850bdf9de2ed8fa025",
               "encrypted_recipient_data": "7298ca5f55f169b2da5495e8fd62fb1d86bc76f15db375d5934fd2b03f9603e59381677771f34b5e7b0ab9f4ad018fb4bcdb"
            }
         ]
      }
   ],
   "invoice_created_at": 1710791154,
   "invoice_relative_expiry": 7200,
   "invoice_payment_hash": "a1ba5e572993eae883c889e3b5157b40ba65c160d7afe26851291e6f12223ce4",
   "invoice_amount_msat": 1000,
   "invoice_node_id": "0230da9545e2f325e86b1a2c49cb29643b9dfcc4c12ab8e932e038ba723a323c18",
   "signature": "7f1b018aab37ef17a7e0067b4d9f11711ca259aff691b639c050d69028b7613648bfceab7b9169fb39bb0fd954397bac8ab2e6d99ad0a9455be5b31a47348be3",
   "valid": true
}

Pay invoice from LND, hex-encoded decrypted encrypted_data is: 020800008900000100000a0800500000000103e80c060000006c03e8

[vincenzopalazzo]

I should look at it because I am interesting in the ldk compatibility too, but maybe @rustyrussell know already what it is going on

[cdecker]

This sounds like we are basing out CLTV calculations on our current sync-height, rather than the blockheader count. We should change that :-)

That being said, I expect this test environment to be automated, and if we didn't poll bitcoind recently we won't be aware of recently generated blocks either. This is specific to the testing environment as on mainnet blocks are not generated in rapid success, which also means we don't end up with the wrong CLTVs.

In case you are using the pyln-testing package, there is a function to allow waiting for blockchain sync: sync_blockheight(bitcoind, [list, of, nodes, to, sync]), do this and the heights should line up again.

[carlaKC]

That being said, I expect this test environment to be automated, and if we didn't poll bitcoind recently we won't be aware of recently generated blocks either

Just running a few nodes manually on regtest and re-tested this today (having not mined any block storms for a good 12h since I was trying this out yesterday) and I still get the same value.

Is there a way for me to check whether my nodes are fully synced? I tried waitblockheight 300 and it returns immediately, and getinfo has the current block height as my other (LND) nodes see it. Logs also have lightningd: Adding block 300 although maybe that doesn't mean it's fully synced?

[cdecker]

Hm, that should indeed be the case, I don't have a good explanation for this one :thinking:

[vincenzopalazzo]

@carlaKC maybe core lightning is not pulling bitcoind during this time? there is a flag that I use lnprototest that is --dev-bitcoind-poll=1 passed to lightnind

Logs also have lightningd: Adding block 300 although maybe that doesn't mean it's fully synced?

mh idk :) we should try to reproduce it

[carlaKC]

@carlaKC maybe core lightning is not pulling bitcoind during this time? there is a flag that I use lnprototest that is --dev-bitcoind-poll=1 passed to lightnind

Tested again with this option and still hitting the same issue - got a max of 108 when on block 148.

[vincenzopalazzo]

Well lets try to look at it during April, thanks for the report @carlaKC