Indeed, sorry, I misunderstood it because I read AMP/keysend and assumed
you were talking about payer-generated preimage.
It doesn't help that "payer" and "payee" are so similar words.

So yes, I agree very much.

I also think the part about including the order details inside the TLV
would be very good to have.

I would say, however, that these are two separate proposals:

  1. implementations should expose a "stateless invoice" API for receiving
using the payment_secret;
  2. when sending, implementations should attach a TLV record with encoded
order details.

Of these, 1 is very simple to do and do not require anyone to cooperate, it
just works.

2 requires full network compatibility, so it's harder. But 2 is also very
much needed otherwise the payee has to keep track of all the invoice ids
related to the orders they refer to, right? But I think just having 1
already improves the situation a lot, and there are application-specific
workarounds that can be applied for 2 (having a fixed, hardcoded set of
possible orders, encoding the order very minimally in the payment secret or
route hint, storing order details on redis for only 3 minutes and using
lnurlpay to reduce the delay between invoice issuance and user confirmation
to zero, and so on).

On Tue, Sep 21, 2021 at 9:41 AM Joost Jager <> wrote:

> On Tue, Sep 21, 2021 at 2:05 PM fiatjaf <> wrote:
>> What if instead of the payer generating the preimage the payee could
>> generate stateless invoices? Basically just use some secret to compute the
>> preimage upon receiving the HTLC, for example:
> Maybe my explanation wasn't clear enough, but this is exactly what I am
> proposing. The payee generates a stateless invoice and gives it to the
> payer.
>> 1. Payer requests an invoice.
>> 2. Payee computes hash = sha256(hmac(local_secret,
>> arbitrary_invoice_id)), then encodes arbitrary_invoice_id into the invoice
>> somehow.
>> 3. Payer sends payment with arbitrary_invoice_id as tlv_record_a.
>> 4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret,
>> tlv_record_a) and resolves it.
> One way to do this that I tried to describe in the initial post is via the
> payment_secret. This is already an arbitrary invoice id that is already
> sent as a tlv record.
>> I've implemented such a scheme on @lntxbot, but it required low level
>> code in a c-lightning plugin and a hack with route hints: since TLV
>> payloads were not an option (as payers wouldn't know how to send them) I've
>> used a "shadow" route hint to a private channel that didn't exist, so
>> preimage was generated on the payee using preimage = hmac(local_secret,
>> next_channel_scid).
> Clever workaround.
> Joost
Lightning-dev mailing list

Reply via email to