LN bug?? CLN invoices without final-cltv-delta set failingcommunity.corelightning.org/c/node-operators/bolt11-generation-problem
7385 sats \ 5 comments \ @niftynei 22 Dec 2023 litdevs
I had this bite me when trying to get StackerNews to pay out my CLN node. Seems like the fix as a CLN noderunner is to always include the final-cltv value. Patch coming :/
Spec says invoices w/o a final-cltv-delta field should be treated as 18blocks by default; seems like some wallets aren’t using a default value
Bug fix in CLN is to always include it; for wallets/other impl it’d be to use the default if not present
Anyone have insight into what’s going on on the other end of this?
write
preview
related posts
770 sats \ 0 replies \ @endothermicdev 22 Dec 2023
This is just nodes decoding the invoice assuming a 9 block cltv delta if not explicitly specified with a c field in the invoice, but the BOLT 11 spec was changed to 18 blocks over three years ago, so that assumption is bad. If your node is decoding incorrectly, it's time to update it to the current standard!
This has been patched with CLN v23.11.2 by always forcing inclusion of the c field so there can be no ambiguity. It would be nice to relax this at some point so that default invoices and QR codes could be more compact. If you're facing this issue with nodes or services unable to pay a CLN 23.11 generated invoice, please update to v23.11.2.
reply
238 sats \ 3 replies \ @k00b 22 Dec 2023
This was so weird to troubleshoot because the invoice looked good. The final cltv delta was the only thing that stood out, which depending on how I decoded it was reported as 9 or not at all.
reply
0 sats \ 2 replies \ @shibe 23 Dec 2023
withdrawals seem to be broken now? Just says "could not decode invoice" on stacker.news regardless of what invoice I put in
reply
1 sat \ 1 reply \ @k00b 23 Dec 2023
I just withdrew fine. To be clear this post is about a protocol interoperability issues you’d only experience if you’re running core lightning.
If you’d like help with your issue, you can share your invoice here or dm me on other socials.
reply
392 sats \ 0 replies \ @anon 23 Dec 2023
The first sentence sounds like CLN is at fauilt in this case. To be clear, the change in the specification was initiated 3 years ago by the LDK team, and LND have simply not followed the spec change.
CLN has a backwards compatibility shim in the invoice generation intended to be there until the rest of the network upgraded to also default to 18 blocks. After 3 years we went and removed this backwards compatibility shim, expecting all nodes to be long updated, but LND had not, and so we re-added that shim.
So, while CLN users would encounter this problem, despite behaving correctly, the larger share of LND nodes out there, forced our hand to take a step backwards rather than forwards...
reply