Author: Bastien TEINTURIER 2021-09-21 15:47:12
Published on: 2021-09-21T15:47:12+00:00
In this email exchange, Bastien and Joost discuss the implementation of a "stateless invoice" API and the use of encoded order details to address the issue of invoice storage as a denial-of-service vector for merchants/hubs. Joost suggests that a new tag for bolt11 and node implementations is needed to carry over the contents of the encoded order details field to a tlv record, which would require senders to support this feature. Bastien asks for an example of what information would usually be put in the encoded_order_details field, suggesting that it could be a skuID from the merchant's product database or fully self-contained data to identify a transaction, encrypted with a key belonging to the payee. They both agree that the encoded_order_details field should be reasonably small to ensure it can fit in onions without forcing the sender to use shorter routes or disable other features. Joost mentions that he has prototyped a stateless invoice API in lnd and that it isn't too involved if implemented so that a regular invoice is inserted 'just in time'.
Updated on: 2023-06-03T05:58:00.420655+00:00