lightninglabs
[bug]: tapd creates an invoice that expires after the quote from the oracle expires
On my price oracle I have a expiry_timestamp set to 300 seconds in the future.
I then create an invoice and don't set the expiry in order to accept the default expiry of 86400 seconds.
tapd happily generates the invoice, but I think it should fail.
price oracle expiration time should always be after invoice expiration time.
Makes sense, when we get the RFQ response/accept back, we should use that to set a custom expiry on the invoice.
Makes sense, when we get the RFQ response/accept back, we should use that to set a custom expiry on the invoice.
One thing I was getting ready to test is do you already do this and I just don't know that I you've reduced the expiry from 86400 seconds to 300 seconds without telling me?
I think the user must have their sats invoice expiry honored and not overridden by a lower quote expiry. If that is the case there are going to be a lot of problems at the application level. If the price quote expiry is less than the invoice expiry, it should error.
I think the user must have their sats invoice expiry honored and not overridden by a lower quote expiry. If that is the case there are going to be a lot of problems at the application level. If the price quote expiry is less than the invoice expiry, it should error.
More specifically, when placing a buy order, we should set the rate hint expiry in the order to the invoice expiry and require this expiry before accepting a quote.
Currently, I think the price oracle of the party generating the invoice tells the node what the rate hint expiry in the buy order should be requested for. Then I think that after a quote is offered, when deciding if the quote should be accepted, the party generating the invoice checks if the expiry of the quote is within bounds of what its price oracle says is OK. This current approach I don't think is specific enough.
The party offering the quote (the edge node) should still use the expiry defined in its price oracle though.
Here's a relevant part of the spec:
https://github.com/Roasbeef/blips/blob/579061b962e0212edf6977fd3138522e43897105/blip-tap.md?plain=1#L1454-L1458