It just made sense to use deschash because when you’re fetching the invoice you can store the zap request directly in the lightning node (at least with CLN, CLN stores the description when creating deschash invoices). so the zapper implementation is insanely trivial on CLN. I just monitor all paid invoices and create a zap from the data stored on the invoice.

The lnurl implementation just talks from my VPS to my node at home over lightning, via commando/lnsocket with a rune that only has permission to fetch invoices.

So i’m already fetching invoices over lightning (in a non-spec’d) way. Maybe bolt12 would make this slightly better, if damus could fetch this directly from the lightning network instead of relying on the web? http is just so useful and easy for most clients though.

Reply to this note

Please Login to reply.

Discussion

it might be trivial on CLN because CLN stores that info (off-band afaik)

but the spec should not assume such a detail of a specific LN implementation.

It ties that zap feature close to that LN implementation and as mentioned makes it hard for other implementations.

If nodes aren’t doing this they are not following spec?

bolt11: “a reader …. MUST check that the sha2 256-bit hash in the `h` field exactly matches the hashed description “

How can it do this without storing the description when creating deschash invoices ?

the reader is the sender’s wallet, right?

this is not a real world case.

that mean for example WoS, etc. would need to somehow also know the zap request to do that check.

this is problem with the ecosystem atm, there is no way to pass a description into the wallet via a lightning link, i added this to my CLN ios wallet but it seems no other wallet does this. It definitely seems like people are not caring about the spec and are just paying deschash invoices without the description… maybe just have to live with that now ?

even if one would pass some random big string to the wallet, what should it do with the zap request for example? (bolt11 and description would come from the same source)

should it show the scary JSON somehow to the user?

the description is used as a short text for humans. that’s what is shown for people.

yes the wallet would have to support parsing that and show a cool zap screen, which isn’t too unreasonable considering the amount of overlap these days. But definitely not good for a general wallet. I imagine people will put lots of weird crap in bolt11 descriptions 😬

assuming a zap request could be shorter than 639 bytes it would also not work.

I don’t know the bolt11 details well enough.

Even if it’s their fault to not implement the bolt11 spec perfectly the state is that some big implementations have this problem.

It limits how zappers can be built. LN implementations have problems, not to talk about tools like lnbits, strike, etc.

those can not be used because of this limitation.

So you just want nip57 to be updated to remove this:

SHA256(description) MUST match the description hash in the bolt11 invoice.

?

basically, yes. making this independent of the bolt11 somehow to allow implementations that have issues with the description hash also be used to receive zaps.

I mainly was curious what’s the reason or if I miss something on why it is in there. (just as lnurl itself has removed it)