Unified QR Code

[augustresende]

Could we adapt LNURL to work with https://bitcoinqr.dev standard?

Related:
sbddesign/bip21-site#70

[RajGoodF]

Any update on this ?

[fiatjaf]

What is needed?

[BitcoinErrorLog]

This should probably be a PR for BIP-21 instead, to formalize extending it for more payment types. The actual work needed would be for wallets and merchants to support variable payment endpoints, as you cannot fit enough detail in a QR to include them all.

This is what Slashtags is working on with its payment (slashpay) features. The original POC is here, and we have a more elaborate implementation in Bitkit wallet.

[augustresende]

This should probably be a PR for BIP-21 instead, to formalize extending it for more payment types. The actual work needed would be for wallets and merchants to support variable payment endpoints, as you cannot fit enough detail in a QR to include them all.

There is a PR in BIP-21 site
sbddesign/bip21-site#70

[RajGoodF]

What is needed?

As we are having single qr for bitcoin onchain address and lightning invoice, can we embed the lnurl pay also with it, so we need a single qr, which have bitcoin onchain address and lnurl-pay. So that at brick-mortar stores can have multiple payments on one qr.

[BitcoinErrorLog]

instead of lightning= just put lnurl= and pray.

[RajGoodF]

I tried that, but phoneix wallet wasn't able to decode it, so not sure is this issue from my end, or the third party wallet.

[BitcoinErrorLog]

You misunderstand how these things work. Updating a spec does not force every wallet to update. I am only saying the simplest way to design what is being asked here. The work of getting every wallet to support it is another effort.

[sbddesign]

I think @BitcoinErrorLog's assessment is correct. I'll add a little more context for you, @RajGoodF.

BIP21 is a spec that's been around for a decade. Here's the spec doc. BIP21 very clearly allows you to create any parameter you want. You could add a silly param like ?potato=12345 to the end and that is a perfectly valid BIP21 URI. However, there's no guarantee that every wallet is going to add support for whatever cool feature the potato param enables. That's sort of the idea: it's meant to be flexible.

BitcoinQR.dev is not really a spec, it's just a site that talks about how you can make a unified lightning and on-chain QR code by using a lightning param in a BIP21 URI. And then it has a log of which software supports this method and some other resources. That's about it.

So absolutely, projects that use LNURL could certainly use BIP21 if they choose. But that probably means talking to wallet projects and building support for extracting a ?lnurl= param from the URI. Or perhaps putting the LNURL data inside the lightning param, and getting wallets to expect that this param might contain a BOLT11 or might contain LNURL data.

But regardless, that's really a matter of talking with wallet projects and building support for this idea. IMHO, that doesn't necessitate updates to any LUDs.

[dennisreimann]

Seems like Zeus, Alby and Wallet of Satoshi (at least partially) support LNURL in BIP21 via the lightning= query string parameter. https://twitter.com/ZeusLN/status/1617622048314101766

Imho it'd make sense to let the wallet figure out the details and not introduce a new param like lnurl=, because there are most likely more additions coming up and the QRs are already dense.

[augustresende]

@dennisreimann officializing this "standard" of accept lnurls in lightning params in the both specs (lnurl and bitcoinqr.dev) would be good. Agree @fiatjaf ?