New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invoices can be paid after expiration #3448
Comments
ahh nvm you mean that LND will receive payments via expired payment requests. Yeah, it does seem like LND will not send to an expired payment request, but it will receive a payment through a payment request that it sets as expired. IMO, this is a bug of the sending side. If everyone refuses to send, then no problem. Rejecting based on the receiving end means you will have to roll back an HTLC which is really bad and can cause issues. So TLDR:
|
BOLT11:
** after the timestamp plus expiry has passed SHOULD NOT accept a payment. ** Eclair wallet acknowledged the issue (ACINQ/eclair-mobile#209) and fixed it for next release. @jackeveritt tested other implementations, those reject payment correctly. |
According to RFC2119: https://www.ipa.go.jp/security/rfc/RFC2119EN.html
|
That being said, I think LND should reject incoming payment to requests they generated with an expiry if that expiry is passed. |
In fact, this is pretty much necessary for exchanges to support lightning using LND. If a user uses a wallet that sends to expired requests, and we accept it even though it's required... then we need to add extra logic to double-check the invoice just in case forever. Which is not realistic. |
This is fixed in PR #3694 and waiting for review. |
Fixed by #3694. |
On version v0.7.1.
We got report of the possibility of paying an LND invoice after it got expired, in violation with BOLT11.
This cause significant problem for merchant because:
There exist a workaround via hodl invoices, but implementing it put the burden of accepting an incoming payment on the shoulder of the LND client.
Because BTCPay is using an abstraction layer for lightning implementation and that hodl invoices can't fit into such abstraction, we can't really use this alternative.
The text was updated successfully, but these errors were encountered: