📅 Original date posted:2021-09-21
📝 Original message:
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.jager at gmail.com> a écrit :
> On Tue, Sep 21, 2021 at 3:06 PM fiatjaf <fiatjaf at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/f31a309c/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:03:50
in reply to nevent1q…axdc
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:03:50Event JSON
{
"id": "807d44e9815d1df1d4c472d762f647eadf7cac501f931e77c1249b19b5302c82",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315830,
"kind": 1,
"tags": [
[
"e",
"e4e7ab359e7c5557c58c3d4556f5e2b70b0dd56c221200159af6ed9115c412d1",
"",
"root"
],
[
"e",
"9a983138a728866a6c885b4aa00461636f98efb6b92a81cb0dd6ee58a4d312f8",
"",
"reply"
],
[
"p",
"ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3"
]
],
"content": "📅 Original date posted:2021-09-21\n📝 Original message:\nHi Joost,\n\nConcept ACK, I had toyed with something similar a while ago, but I hadn't\nrealized\nthat invoice storage was such a DoS vector for merchants/hubs and wasn't\nsure it\nwould be useful.\n\nDo you have an example of what information you would usually put in your\n`encoded_order_details`?\n\nI'd imagine that it would usually be simply a skuID from the merchant's\nproduct\ndatabase, but it could also be fully self-contained data to identify a\n\"transaction\"\n(probably encrypted with a key belonging to the payee).\n\nWe'd want to ensure that this field is reasonably small, to ensure it can\nfit in\nonions without forcing the sender to use shorter routes or disable other\nfeatures.\n\nCheers,\nBastien\n\n\nLe mar. 21 sept. 2021 à 15:17, Joost Jager \u003cjoost.jager at gmail.com\u003e a écrit :\n\n\u003e On Tue, Sep 21, 2021 at 3:06 PM fiatjaf \u003cfiatjaf at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e I would say, however, that these are two separate proposals:\n\u003e\u003e\n\u003e\u003e 1. implementations should expose a \"stateless invoice\" API for\n\u003e\u003e receiving using the payment_secret;\n\u003e\u003e 2. when sending, implementations should attach a TLV record with\n\u003e\u003e encoded order details.\n\u003e\u003e\n\u003e\u003e Of these, 1 is very simple to do and do not require anyone to cooperate,\n\u003e\u003e it just works.\n\u003e\u003e\n\u003e\u003e 2 requires full network compatibility, so it's harder. But 2 is also very\n\u003e\u003e much needed otherwise the payee has to keep track of all the invoice ids\n\u003e\u003e related to the orders they refer to, right?\n\u003e\u003e\n\u003e\n\u003e Not completely sure what you mean by full network compatibility, but a\n\u003e network-wide upgrade including all routing nodes isn't needed. I think to\n\u003e do it cleanly we need a new tag for bolt11 and node implementations that\n\u003e carry over the contents of this field to a tlv record. So senders do need\n\u003e to support this.\n\u003e\n\u003e\n\u003e\u003e But I think just having 1 already improves the situation a lot, and there\n\u003e\u003e are application-specific workarounds that can be applied for 2 (having a\n\u003e\u003e fixed, hardcoded set of possible orders, encoding the order very minimally\n\u003e\u003e in the payment secret or route hint, storing order details on redis for\n\u003e\u003e only 3 minutes and using lnurlpay to reduce the delay between invoice\n\u003e\u003e issuance and user confirmation to zero, and so on).\n\u003e\u003e\n\u003e\n\u003e A stateless invoice API would be a great thing to have. I've prototyped\n\u003e this in lnd and if you implement it so that a regular invoice is inserted\n\u003e 'just in time', it isn't too involved as you say.\n\u003e\n\u003e Joost\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210921/f31a309c/attachment.html\u003e",
"sig": "2835fa6a289e13e6ea58900c156d8bfe1dd937e8d880c8c6f6362194be925c78febb323a2f770c0fc7e7ee113c6adde899dad94cf4413d941610cf790a377e37"
}