LNURL-verify

[reneaaron]

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!

[arcbtc]

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.

[fiatjaf]

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.

[fiatjaf]

It was pointed to me that the comment above was being interpreted as trolling, here is my response: https://t.me/lnurl/33515

[fiatjaf]

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:

1. The UX, because having to find and write a bunch of API keys or IP addresses is a pain even for seasoned programmers;
2. 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.

[earonesty]

@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.

[fiatjaf]

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.

[earonesty]

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.

[john-zaprite]

"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.

[zzzhan]

Good for the Internet money

[uncleJim21]

"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.

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.

[supertestnet]

The list of services that support lnurl-verify is growing.

Service	LNURL-verify support
Alby	✓
Stacker News	✓
Mutiny Plus	✓
Bitcoin Connect	✓

Some tools also require it:

Service	LNURL-verify required	Proof
Scrib	✓	proof
Nostream	✓	proof

It would be great if it was merged as standard

Please do it

[TonyGiorgio]

We have multiple implementations of this and it's very useful, let's go ahead and merge it in.

[TonyGiorgio]

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?

[reneaaron]

@TonyGiorgio I just submitted a PR, let me know if I missed anything:

#264

[RajGoodF]

What is the use of sending pre image in verify api response ? @reneaaron @TonyGiorgio @john-zaprite

[john-zaprite]

What is the use of sending pre image in verify api response ?

At Zaprite, we check the invoice is paid by validating the preimage with the payment request.

[RajGoodF]

How do you validate pre image with payment request @john-zaprite ? can you share some snippet

[john-zaprite]

This package has an isValidPreimage function …
https://www.npmjs.com/package/lnurl-pay?activeTab=readme