search

ElementsProject / lightning

Core Lightning — Lightning Network implementation focusing on spec compliance and performance
Other
2.85k stars 902 forks source link

can't have two offers with the same description #7711

Open AndySchroder opened 1 month ago

AndySchroder commented 1 month ago

With

lightning-cli offer -k "amount"="any" "description"="test10" "label"="testing offers"

and

lightning-cli offer -k "amount"="any" "description"="test10" "label"="testing offers2"

we can't have two offers with the same description. Changing the label results in the original offer being returned instead of creating a new offer with the new label. Is the offer_metadata field of offers even used?

Why have a label feature if it can't be used?

In light of https://github.com/ElementsProject/lightning/issues/7710, this is problematic. Also, with https://github.com/ElementsProject/lightning/issues/7709, I don't know how to re-create an offer if the first one had no blinded paths and I want an offer with a specific description and blinded paths.

vincenzopalazzo commented 1 month ago

In this case, the label is not a key like in the invoice, probably this is confusing from the API point of view.

However, offers with the same description and amount should be the same offer, modulo if your blinded path is not changing on the fly

rustyrussell commented 1 month ago

I'm not sure how we would know which offer they're trying to pay though?

AndySchroder commented 1 month ago

What is offer_metadata for then?

vincenzopalazzo commented 1 month ago

What is offer_metadata for then?

See https://github.com/lightning/bolts/blob/master/12-offer-encoding.md#rationale-1 - Wondering if we can use it as an identifier.

Probably you are trying to describe xy problem and are we missing the use case that you are trying to achieve?

AndySchroder commented 1 month ago

Example problems:

  1. You have an existing offer with a description and you want to create a new one with blinded paths instead of directly exposing your node, or you just need to update the blinded paths to new ones, or you want to have different offers with different blinded paths for different people or expected payment sizes.
  2. You use single use offers and sell the same product to multiple people and you therefor have the same description for each subsequent sale of the same product. Or, you want to have a generic description for all sales for different products.
  3. You want to sell the same product at multiple locations and you want to be able to track where the product was sold by using different offers and you don't want the customer or your employees to know that.
  4. You want to give out different offers over time with the same description to track when people discovered the offer without them knowing that.
  5. You want to be able to give a different offer to everyone with the same description and know who paid you and also be able to choose to not receive payment from certain people at any point in time.
vincenzopalazzo commented 1 month ago

Only point one is enough for me, thanks for sharing

Regarding 2, 3 I think make multiple offer is an hack, we need to extend the bolt12 for this kind of market place usage.

I do not understand 4 because you already know at fetchinvoice time these information, probably you can do something similar with 5 too but not sure.

However, point 1 sounds good to analyze and work on allow people to replace a previous offer

AndySchroder commented 1 month ago

I do not understand 4 because you already know at fetchinvoice time these information, probably you can do something similar with 5 too but not sure.

I disagree. They may see the offer, bookmark it, then later pay it several times at different times.

AndySchroder commented 1 month ago

Regarding 2, 3 I think make multiple offer is an hack, we need to extend the bolt12 for this kind of market place usage.

That is what I am "thinking" offer_metadata is for, but I really don't know the intention for that in the spec.