Feature request: Allow invoice creation with description_hash instead of description.

[Kukks]

BOLT11 specifies that an invoice must be created with description OR description_hash. However, CLightning only allows description. A previous attempt was made by @fiatjaf in #3045 but was abandoned.

It seems like it should not be too hard to implement this (as fiatjaf actually has a plugin doing just this https://github.com/fiatjaf/sparko/tree/master/invoicewithdescriptionhash). Unfortunately, my C experience is laughable and would go far to get the ball rolling.

The reasoning for wanting this baked in instead of a plugin is because I would not expect or demand users on BTCPay to install a lightning plugin (requires handling some bash commands which may be too much for some) for a feature that is part of the base spec.

Use-case: LNURL-pay

[vincenzopalazzo]

I think that this functionality was removed in some release ago, as rusty describe in the PR.

I ripped that functionality out a few versions ago. There's currently no transport which handles an external description, so the recommendation is to avoid description_hash for now.

And, according to with fiatjaf comment (reported below), the offers that are finally out can solve this problem in a better way?

I didn't think that transport should be something standardized and specified in the BOLTs. But now if we're going to have "offers" that could be it.

P.S: Not a expert with LN-URI, I can missing somethings

[Kukks]

I think that this functionality was removed in some release ago, as rusty describe in the PR.

I ripped that functionality out a few versions ago. There's currently no transport which handles an external description, so the recommendation is to avoid description_hash for now.

And, according to with fiatjaf comment (reported below), the offers that are finally out can solve this problem in a better way?

I didn't think that transport should be something standardized and specified in the BOLTs. But now if we're going to have "offers" that could be it.

P.S: Not a expert with LN-URI, I can missing somethings

The lightning implementation shouldn't be concerned of how I transport a trivial string, just provide a hash for the payee to verify it on their own.

Bolt12 may offer another way but I would like to also support other solutions which also utilize the bolt11 spec.

[laanwj]

Also ran into this. It doesn't even mention the need for description_hash in the main LNURL specs but somehow at least Phoenix seem to require it e.g. ACINQ/phoenix#213

The go plugin is quite hacky, it reads hsm_secret directly to get the private key to re-sign the invoice after adding the description hash. Would be way preferable to have it built in. But I also understand the reasoning not to. It's kind of annoying.

[laanwj]

I'm not going to PR this if it's controversial, but FWIW here's a branch that adds an optional description_hash parameter to invoice (it needs to be a 64-digit hex hash, and description needs to be empty for it to work): https://github.com/laanwj/lightning/tree/2021-10-description-hash

[hsjoberg]

Also ran into this. It doesn't even mention the need for description_hash in the main LNURL specs

@laanwj There's a mention (or two) in the LNURL-pay LUD-06 specification about metadata hashed in desc hash tag:

and

...but admittedly this isn't very clear, so definitely something to look into. Perhaps there could be a short description on how LNURL-pay works before jumping into the wallet flow section.

[vincenzopalazzo]

...but admittedly this isn't very clear, so definitely something to look into. Perhaps there could be a short description on how LNURL-pay works before jumping into the wallet flow section.

Concept ack.

[laanwj]

@laanwj There's a mention (or two) in the LNURL-pay LUD-06 specification about metadata hashed in desc hash tag:

Thanks! I missed that part. I think I searched for description_hash and descriptionHash, which didn't turn that up (only a match in LUD-18).

[laanwj]

but FWIW here's a branch that adds an optional description_hash parameter to invoice

So I did PR it, and I think the PR (#4892) is more or less ready, but it could use some testing and review/ACKs.