Proposal for LUD-03 spec addition: wallet must nod send an invoice with tag h in callback

[johnzweng]

• In LUD-03 in the callback the LN WALLET send a Bolt11 Lightning payment request (invoice).

• Bolt11 allows that a payment request might contain only a hash of the description (tag h)

• Bolt11 specifies that if the tag h is present in a payment request a lightning node:

  - MUST check that the SHA2 256-bit hash in the `h` field exactly matches the hashed description.
  

• To be able to do so, a lightning node must learn the preimage together with the bolt11 payment request (containing a hashed description) before it can initiate a payment.

Consequence:

• The (receiving side) LN Wallet must also provide the pre-image of the hashed description used in the Bolt11 payment request (aka LN invoice).
• Thus LUD-03 would need to be extended, so that if a LN WALLET uses tag h in the generated Bolt11 payment request, it also MUST return the preimage of tag h in its callback.
• LUD-03 should make this mandatory and introduce an additional GET parameter for the callback (in addition to already existing k1 and pr).

[johnzweng]

Or as an alternative: we could require that LN WALLET MUST NOT use tag h in returned Bolt11 payment requests, but instead is only allowed to use tag d.

[fiatjaf]

Both service and wallet already know the preimage of the hashed description. It is the metadata.

[johnzweng]

I'm talking about withdrawRequest, not payRequest. Where do we have metadata there? There is only defaultDescription, which the LN WALLET might use as description for the payment request (aka Bolt11 invoice), but I don't see that this is required.

[fiatjaf]

There is no description hash on withdrawRequest.

[johnzweng]

Sorry, maybe I understood something wrong here. I was thinking of the following flow:

• User wants to buy BTC at an ATM and inserts cash
• ATM displays a LNURL-withdraw QR code
• User scans QR code with his wallet, user's wallet makes first GET request to LN SERVICE
• LN SERVICE (ATM) responds with JSON containing callback URL and k1 string and amount infos (min/max)
• Users wallet generates an invoice matching the amount constraints and sends this generated invoice in a second GET request to the callback URL (query parameter pr=)

And I was thinking about this last step:

• the invoice is generated by the user's wallet
• besides the amount there is no restriction specified how the invoice generated by the user's wallet has to look like
• the user's wallet could include any payment description (tag d) or not
• and as far as I had understood, the user wallet also could return an invoice containing an h tag (as it's the user's wallet controlling which invoice it creates).

If it would return an invoice containing a hash (tag h) the LN wallet behind LN SERVICE (aka ATM) would not be able to pay this invoice (as it would need the preimage, too) if it would strictly follow Bolt11.

Did I get this flow wrong?

[fiatjaf]

The wallet shouldn't make an invoice containing a h in this flow. But what if they do?

I mean, what if you owe me money for an ice cream and you ask me to give you an invoice, then I make an invoice with an h? Will you refuse to pay it? What if I have a normal description saying "payment for a new shoe"? Would you refuse to pay that because it doesn't say "ice cream"? It's all very subjective and there is no way around it.

NIP-06 has more structure to it, but even then nothing is guaranteed.

[johnzweng]

Yeah, I understand. Also I don't assume that any currently existing wallet would include an h.

Maybe we could add a suggestion to the withdrawRequest spec that a wallet should not send an invoice using h?

I guess it's not important what actually is written in the description (that's subjective as you said) but more important that there is anything. I guess that's Rusty's concern with this. A node (or a node's external signer) might have interest in having at least some infos (for their internal transaction list, for bookkeeping, whatever..).

[fiatjaf]

The spec is bad, the description should be actually be defined in the spec as some templated string, otherwise it's useless and dangerous. Having a description helps no one as it will be paid blindly by the service. Rusty's concerns are not satisfied anyway.

I used to agree with Rusty's point about having descriptions and signatures and paying attention to these things, but it's a waste of time, no one cares about the signatures or the descriptions.

[johnzweng]

Yes, hmm.. You're right. It's the whole point of withdrawRequest that the service pays whatever invoice the user provides (as long as the amount matches).

Nevertheless a wallet never should send an invoice with h as this will prevent the service's nodes from paying (if it strictly adheres to Bolt11).

But it's in the interest of the wallet to receive the funds, so I guess no wallet has an incentive of doing so. As the spec already exists in this form, it might be useful to add this note, to LUD-03.

I changed the title of this issue to reflect this.