You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the invoice metadata is stored in the DB forever.
This isn't necessary from a company's point of view, because 1) the invoices are already stored in the LN node and 2) companies that need to keep invoices around for a couple of years need additional data anyway, so the metadata in the ln-paywall storage aren't of use here.
And it's also not necessary from an implementation point of view (since #24), because 1) LN invoices expire after some time (can be configured when creating the invoice), so when an invoice isn't paid until its expiry, the metadata is of no use anymore, and 2) due to the final request now only working when the DB has a metadata entry about the corresponding initial invoice request, cheating with reusing preimages that aren't in the storage doesn't work.
The two cases in detail:
Invoice request is sent, metadata is created. The invoice expires after 1 hour (default in the LN protocol standard, see BOLT 11.
If the client doesn't pay within 1 hour, we can throw away the metadata anyway, because the client is technically not able to pay the invoice later (due to invoice expiry).
If the client does pay within 1 hour, we should give him some time to send the final request, but that shouldn't be unlimited. Considering the programmatic nature of HTTP requests, a shorter expiry might make sense (invoice payment is often done by humans, with wallet software which might require some channel syncing first etc.), but 1 hour might be fine as well. This needs to be configurable.
Invoice request is sent, metadata created, final request sent, metadata marked as "used", so everything is done. Until Fix a client can cheat with using the wrong preimage for a request #24 the preimage needed to be kept around in storage, because otherwise a client could just use any preimage that corresponds to an invoice in the LN node and the middleware would have accepted it, but now, if a request contains a preimage, which is not in the storage, it's rejected immediately! BUT the error message might confuse clients that accidentally reuse a preimage in a second request. So for usability reasons the metadata should be kept around for a bit as well. This expiry should not start from the invoice creation, but the use (the final request).
So:
Unused metadata should be kept for 1 hour (configurable) after invoice creation, to give the client time to send the final request after payment
Used metadata should be kept for 1 hour (configurable) after usage, to give the client proper error messages when reusing a preimage
The text was updated successfully, but these errors were encountered:
Currently the invoice metadata is stored in the DB forever.
This isn't necessary from a company's point of view, because 1) the invoices are already stored in the LN node and 2) companies that need to keep invoices around for a couple of years need additional data anyway, so the metadata in the ln-paywall storage aren't of use here.
And it's also not necessary from an implementation point of view (since #24), because 1) LN invoices expire after some time (can be configured when creating the invoice), so when an invoice isn't paid until its expiry, the metadata is of no use anymore, and 2) due to the final request now only working when the DB has a metadata entry about the corresponding initial invoice request, cheating with reusing preimages that aren't in the storage doesn't work.
The two cases in detail:
So:
The text was updated successfully, but these errors were encountered: