pull down to refresh

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?
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
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
withdrawals seem to be broken now? Just says "could not decode invoice" on stacker.news regardless of what invoice I put in
reply
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.