From fiatjaf at gmail.com Tue Sep 21 13:05:48 2021 From: fiatjaf at gmail.com (fiatjaf) Date: Tue, 21 Sep 2021 10:05:48 -0300 Subject: [Lightning-dev] Stateless invoices with proof-of-payment In-Reply-To: <CAJBJmV9JcVxE9nAir4WwR5A2Csum+PV-o4KqsqK5NLZBMRpZQg@mail.gmail.com> References: <CAJBJmV_nazFFf1SDhzo2gLRDe+ASChPxWKPM4zG9ObtyaXz6KQ@mail.gmail.com> <CAEjd=rqgp3KewOwOHHfhF75tP3KD0bXXijKVGsyY4--mbM0vgQ@mail.gmail.com> <CAJBJmV9JcVxE9nAir4WwR5A2Csum+PV-o4KqsqK5NLZBMRpZQg@mail.gmail.com> Message-ID: <CAEjd=rq2=CgyKi2r257s-qX6VmAuS-yT+gbF-VW2Q7cDas0F6w@mail.gmail.com> 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.jager at gmail.com> wrote: > On Tue, Sep 21, 2021 at 2:05 PM fiatjaf <fiatjaf at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/5b0b8328/attachment-0001.html>