Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-09-21 📝 Original message: On Tue, Sep 21, 2021 at ...
📅 Original date posted:2021-09-21
📝 Original message:
On Tue, Sep 21, 2021 at 5:47 PM Bastien TEINTURIER <bastien at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/0690ebf4/attachment-0001.html>;
📝 Original message:
On Tue, Sep 21, 2021 at 5:47 PM Bastien TEINTURIER <bastien at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/0690ebf4/attachment-0001.html>;