On Tue, Sep 21, 2021 at 5:47 PM Bastien TEINTURIER <bast...@acinq.fr> wrote:
> 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. > Yes, I definitely think it is. Especially in a future where LN invoices are generated casually everywhere. I started a PR on lightning-rfc to explore the impact points. https://github.com/lightningnetwork/lightning-rfc/pull/912 > 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). > I think it depends on the application. For a paywall it could be the article id and an identifier for the user - perhaps a cookie in the user's browser. But it could indeed go as far as a list of skus and the physical delivery address for the goods. That obviously won't be suitable for every application because of the limited space. Passing a full online supermarket shopping cart in the tlv payload is probably stretching it too far. Last year, me and my former colleagues Oliver and Desiree ran tlvshop.com. The site is offline now, but still viewable at https://joostjager.github.io/tlvshop.com/. If you fill out all the fields, it encodes the data into a (non-standard) tlv field. In the case of tlvshop, the payment is truly spontaneous. However the idea of encoding metadata is the same. Attaching metadata to a payment is almost impossible with traditional payments. Lightning changes this and I think that is also a great opportunity to rethink typical design patterns for ecommerce applications. > 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. > I don't know if something bad can happen if the sender is forced to use shorter routes. Maybe as a method to shape traffic in a certain way? Not totally sure, but perhaps this is already possible today by creating bogus route hints. In general I'd say that too much metadata just decreases the payment success rate and therefore something the payee will consider when creating the invoice. A reasonable cap is an easy fix to address any doubts on this front though. Only what constant to pick... Joost.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev