Still wrapping my head around the description_hash affair with Core Lightning (see https://twitter.com/callebtc/status/1635216854577991681 by #[0] ), but as much as I understand the devs concerns, it seems to me that bolt11 makes it quite clear that it is the lightning implementation's responsibility to check that the description and its hash match.
https://github.com/lightning/bolts/blob/master/11-payment-encoding.md?plain=1#L215
Yeah, if I was the boss I would take out that part of the spec where it says:
"if `h` is included MUST make the preimage of the hashed description in `h` available through some unspecified means."
LNURL does that on the app layer. CLN doesn't have to do it again. I wonder what's the purpose of a description hash field if you still have to pass around the description itself.
Anyway, this hasn't been a complete surprise for everyone. I and others have been commenting on the use of description_hash in CLN and what it means for LNURL apps but they gave any meaningful reaction to it.
Example: https://github.com/ElementsProject/lightning/pull/5747#issuecomment-1454955649
That's for the writer. The specification states that the reader must check description and hash concordance.
See my answer to #[3]. Imo we should amend the specification in some way, but that's where we are now.
Also, I think the point of using the description_hash instead of the description is for descriptions that are too big. You just put a fixed-size description hash in the invoice, and transport the description itself via another method (nostr message, avian carrier, etc.).
Currently, per the spec, you MUST pass it to the payer because the payer MUST verify that hash(description) = description(hash). That's why I thing transforming those MUSTs into SHOULDs would be the least bad idea for everyone's sanity.
No. It says it must be checked through “some unspecified means”.
This unspecified means in practice always means the LNURL-pay server.
What I read is that the writer must make the description available through unspecified means, while the reader must ensure description and description_hash match. That's two distinct things.
The problem here is to know how the reader can get knowledge of the description. According to LUD06, that's the job of the LN wallet (https://github.com/lnurl/luds/blob/luds/06.md?plain=1#L108). Per this two pieces of specification, a LN wallet should pass the LNURL metadata as description to the underlying Lightning node when trying to pay the invoice.
Not saying it's good or not, just pointing out that this is the direct consequence of how the specifications are phrased.
