Hi Joost, Concept ACK, I had toyed with something similar a while ago, but I hadn't realized that invoice storage was such a DoS vector for merchants/hubs and wasn't sure it would be useful.
Do you have an example of what information you would usually put in your `encoded_order_details`? I'd imagine that it would usually be simply a skuID from the merchant's product database, but it could also be fully self-contained data to identify a "transaction" (probably encrypted with a key belonging to the payee). We'd want to ensure that this field is reasonably small, to ensure it can fit in onions without forcing the sender to use shorter routes or disable other features. Cheers, Bastien Le mar. 21 sept. 2021 à 15:17, Joost Jager <joost.ja...@gmail.com> a écrit : > On Tue, Sep 21, 2021 at 3:06 PM fiatjaf <fiat...@gmail.com> wrote: > >> 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? >> > > Not completely sure what you mean by full network compatibility, but a > network-wide upgrade including all routing nodes isn't needed. I think to > do it cleanly we need a new tag for bolt11 and node implementations that > carry over the contents of this field to a tlv record. So senders do need > to support this. > > >> 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). >> > > A stateless invoice API would be a great thing to have. I've prototyped > this in lnd and if you implement it so that a regular invoice is inserted > 'just in time', it isn't too involved as you say. > > Joost > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
