LNURL-verify
reneaaron opened this issue · 14 comments
LUD-[TBD]: verify base spec.
author: [TBD] discussion: [TBD]
The idea here is that a SERVICE can verify an invoice has been paid by contacting the LN SERVICE.
A SERVICE can verify a payment was made without access to the user's node. Users can give their LNURL or Lightning Address to a SERVICE and allow the SERVICE to create and verify invoices on their behalf.
This allows users to re-use existing wallets and SERVICEs to facilitate P2P payments without being an intermediary.
LNURL-verify
An optional field verify is added to the callback response:
{
"status": "OK",
"routes": [],
"pr": "lnbc10...",
+ "verify": "https://example.com/verify/894e7f7e...",
}The field verify provides an URL to a SERVICE to check if the invoice has been settled:
https://example.com/verify/894e7f7e...
Response
{
"status": "OK",
"settled": true,
"preimage": "123456...",
"pr": "lnbc10..."
}{
"status": "OK",
"settled": false,
"preimage": null,
"pr": "lnbc10..."
}or
{
"status": "ERROR",
"reason": "Not found"
}Looking forward to hear your feedback!
Glad to see an lnurl-verify spec. Lnurl protocol devs hate it, but I know a bunch of people who ahve been asking for this.
I do think preimage and PR should be optional returns. the service might only store a checking id, which is expressed in the verify callback response.
I think this is an attack on Lightning since it incentivizes lazy companies that want to be "non-custodial" to write services that require users to have a Lightning Address to work, thus excluding people running home nodes and noncustodial mobile wallets.
It was pointed to me that the comment above was being interpreted as trolling, here is my response: https://t.me/lnurl/33515
Every time this idea is brought up I say basically the same thing and I'm yet to see a counter-argument, so let me say here again: if services want to offer noncustodial Lightning services, they must not abuse the LNURL-pay protocols. That is ugly, hacky, error-prone, perverts the protocol and distorts the entire framework upon which bolt11 invoices relies on (because Lightning invoices are meant to have a meaningful description and a signature with which a payment can be proven later on, and by abusing lnurl paycodes meant for donations everything becomes murky and unprovable).
Instead they must do like https://lnbits.com, https://payaddress.co, https://getalby.com or https://bridgeaddr.fiatjaf.com, for example, do: offer a way for people to plug whatever provider they already have and then use whatever API these services have to generate invoices and verify if these were paid.
Libraries like https://github.com/fiatjaf/makeinvoice and https://github.com/lnbits/relampago (I know there are others for other languages but I can't remember their names) are meant to abstract the tedious work involved in supporting more and more providers.
There are two problems with this idea:
- The UX, because having to find and write a bunch of API keys or IP addresses is a pain even for seasoned programmers;
- Every new provider -- either a custodial provider or a self-hosted node -- will bring a new API that will keep adding burden to the maintainers of these libraries and to the services that intend to be noncustodial;
My suggestion is to create a protocol that encompasses the existing APIs, abstracts out the basic functionalities (create invoice, hold invoice etc.) and turns all them into standardized pastable strings, kinda like LNDConnect, but for all nodes and providers. For example, if I want to connect my LND I would paste a string like lnd1abcmnoxyz... that would be provided to me by LND itself and contain the IP address, macaroon and whatever else is needed; if I want to connect an LNbits instance I'll paste lnbits1abcmnoxyz... and so on. The services would then just pass these strings to the libraries and the libraries would know how to translate the lnbits1... string into proper API calls to the LNbits server. This is how 1 is solved.
And this is also how 2 is solved, because once this protocol gets some level of adoption, a newcomer to the space -- let's say, the https://github.com/fiatjaf/cliche node implementation -- will not want to implement its own new API using different secrets, techniques, method names and parameter formats. Instead it will want to reimplement one of the already existing standards, so that it will be immediately compatible with all the libraries and services that use that standard -- i.e., instead of creating a new cliche1... pastable string and waiting for services to implement support for that I could just hand to the user a string like lnd1... and then everybody would immediately be happy.
@fiatjaf this doesn't solve the problem of "im building a websites and i want to throw an invoice in front of someone payable to an lnurl address that isn't me... and verify that the invoice got paid"
which lnurl-verify solves nicely. and does so in a way that i am trusting the owner of the domain to verify however they see fit.
Putting it like that it does sound like a good idea. I still stand by my comments above but today I would be more flexible on the real world use cases.
However, I don't think this repository can change anymore, there are way too many providers no one is going to implement whatever we discuss here, so it's better to not confuse people.
If most implementors start to do this then we can create a LUD with whatever they're doing. Hopefully they will come here and agree on an actual standard first.
apparently most services and daemons implement it anyway (muun, wos, etc.), so it's good enough for me. really should be in the spec tho.
"im building a websites and i want to throw an invoice in front of someone payable to an lnurl address that isn't me... and verify that the invoice got paid"
This is exactly Zaprite's use-case, and LNURL-verify would seem to be a great solution for us.
Good for the Internet money
"im building a websites and i want to throw an invoice in front of someone payable to an lnurl address that isn't me... and verify that the invoice got paid"
This is exactly Zaprite's use-case, and
LNURL-verifywould seem to be a great solution for us.
I agree with John. I am building a site called CASCDR https://cascdr.vercel.app that facilitates paid Lightning APIs between users and service providers. We need to make it easy for service providers to check invoice status even without having a node running in the same environment as the service itself.
LNURL-verify is very useful for this which is why Alby has been tremendously helpful in our early stages. We would love it if more implementations included this as it would expand interoperability across the network at very low cost.
We have multiple implementations of this and it's very useful, let's go ahead and merge it in.
This needs a PR. I think it's safe to assume there's many implementations now of this so once a PR is made, we can merge it in. @reneaaron or anyone else feels like taking this on?
@TonyGiorgio I just submitted a PR, let me know if I missed anything: