Replying to Avatar Fanis

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.

https://github.com/lightning/bolts/blob/33098ad37a442a7677c246ea9e195b7260abe8d2/11-payment-encoding.md?plain=1#L173-L176

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

Reply to this note

Please Login to reply.

Discussion

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.