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 <joost.ja...@gmail.com> wrote: > On Tue, Sep 21, 2021 at 2:05 PM fiatjaf <fiat...@gmail.com> 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 Lightningfirstname.lastname@example.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev