LNURL use cases

[openoms]

LNURLpay

is similar to what the already implemented LigthningAddress does, but is not human readable.

Paying to an LNURLp string is already supported:

• can be pasted in the pay field as well as a LigthningAddress or BOLT11 invoice
• when scanned with the phone NFC the BBW wallet does not yet pop up as an option to pay it

Generating an LNURLp string is not supported currently, but you can convert a Lightning Address from BBW.
For example:

• [email protected]
• Paste to lightningdecoder.com shows the Callback URL:
  https://ln.bitcoinbeach.com:443/.well-known/lnurlp/openoms
• it is a bech32 encoding away from the LNURLp string:
  lnurl1dp68gurn8ghj7mrw9e3xjarrda5kucn9v93kstnrdakn5dp5xvhjuam9d3kz66mwdamkutmvde6hymrs9ahhqetwdakhxpjp8xx

This string can be loaded to the cheapest NFC stickers (will link some) and allows the scanner to pay to the account when scanned.
Currently Zeus, SBW and the Blixt wallet pops up on my Android phone when scanning such a string.

These can be useful for (offline) street merchants as an alternative to the printed QRcodes and can even put on merch, cards or anything coming to mind.
Related: GaloyMoney/blink-mobile#316

LNURLwithdraw

Being able to generate an LNURLw string would allow paying with the link while offline.
It can be loaded to an NFC sticker or card as well for contactless support or just support offline usage of the wallet app.
This is quite insecure as there are no checks in place how much is being pulled of it and the string is reusable. Think of it like a faucet.

To be able to receive by scanning an LNURLw string allows withdrawing from certain ATMs including DIY / FOSS ones like the LightningATM or the BleskoMat
Related: GaloyMoney/blink-mobile#415

[agbegin]

Copying some notes in here that @vindard and I penned before realizing this idea was already quite thoroughly laid out.

Recently had a chat with CoinCorner folks, as some community projects have been showing interest in the BOLT card.

With a few updates, we can enable users of Galoy wallets to send funds from their default wallet using a BOLT card or similar NFC-enabled payment solutions as listed in original post.

Features to enable:

• Enable sending from your default wallet
• Max amount – built into LNURL withdrawal
• Max # of times – not built into LNURL withdrawal

Tasks:

• Implement the LNURL-withdraw flow to enable withdrawal of funds from a Galoy wallet
• Optional: gate to limit the # of times an LNURL-withdrawal link can be used before unlocking it again (security concerns)
  • Look up planned new LNURL protocol extension to include unique hashes with each withdraw link

[openoms]

List of Sticker types:
https://www.wakdev.com/en/more/wiki/apps/nfc-chips-for-nfc-tools.html
In Paralelni Polis NXP NTAG 215 types were used carrying an LNURLw or LNURLp string each for an LNbits wallet on https://wallet.paralelnipolis.cz/ (more info at https://www.paralelnipolis.cz/en/wallet/)

Prices are generally from $0.5 - $1 per sticker/card depending on the order size and location. Are available on amazon, ebay, aliexpress.

[za-kk]

Just adding some notes here regarding BOLT card integration...

To support BOLT card the flow requires standard lnurlw integration in addition to lud-17 (https://github.com/fiatjaf/lnurl-rfc/blob/luds/17.md), lud-17 is required on the BOLT card to allow the added security feature of a unique lnurlw on every tap.

Gift card style BOLT cards are compatible with the normal lnurlw flow (without the need of extra luds) as they don't have the added security as @openoms mentioned above.

[openoms]

There are bounties now:
LNURLpay: #1412
LNURLwithdraw read: #1417
LNURLwithdraw generate: #1418

[strangebit]

BOLT Cards

AFAIK CoinCorner BOLT cards use NXP NTAG 424 DNA NFC chips, which have a feature called Secure Unique NFC message (SUN). The tag is initialized by the user's phone with an AES-128 secret key (in cooperation with the LN SERVICE), and it is set up to generate a unique LNURL-withdraw payment code every time that the user taps the card. LUD-17 would be required as the card cannot do Bech32 encoding.

The LN SERVICE would also know the secret key that was flashed onto the card, and can use it to validate payment requests. The user's phone app can forget the secret after it has initalized the card. Using the secret, the LN SERVICE can be confident that the payment request could only have been generated by the card itself. If the payment request is successfully validated, the LN SERVICE will authorize the merchant to pull funds using LNURL-withdraw.

The following explains in basic terms how the SUN feature works on the NTAG 424 DNA:
https://nfcdeveloper.com/blog/2021/12/01/how-does-dynamic-url-work.html

The following is a good resource that explains how to initialize the NTAG 424 DNA for the LNURL-withdrawPOS purpose:
https://www.whitewolftech.com/articles/payment-card/

Using a special-purpose NFC writer like the Identiv uTrust 3700 F to initalize the card should not be necessary ultimately, as CoinCorner manages to do it with the users' own phones from an Android and iOS app. Likewise with this tutorial app.

Every time that the user taps the card, a new unique request is generated by the card. That way, there should be no replay attack potential, as the LN SERVICE would only process a withdrawal once for each unique payment code. To do this, the LN SERVICE should validate that the current-request card tap counter is greater than the previous-request card tap counter^†. This means that the merchant cannot just save the payment code and keep requesting a payment over and over again to drain your funds. The merchant also cannot just increment a counter in the URL, as the counter is encrypted by the card using AES-128, and only the LN SERVICE can decrypt it and verify the signature using the secret. Therefore, there should be no reasonable possibility for brute force attempts at the URL endpoint, i.e. an attacker guessing URLs until they find one that works.

Think of using the card like you would think of using loose change in daily retail contexts for buying a packet of crisps, or a chocolate bar, or a coffee and a sandwhich, etc. To make it reasonably secure, the LN SERVICE should enforce limits on how much can be spent. Safe defaults should be chosen here, but these limits could also be user-configurable in the app (including freezing/cancelling the card). Perhaps a reasonable safe maximum should also be chosen that the user cannot exceed (say $100), in order to prevent users from shooting themselves in the foot. So for example, a user could set it up so that each payment code can only be used for a maximum of $30. In this case, the merchant does not have to (and should not) take the maximum of $30 though. So for example, if the user is only purchasing a $5 item, the merchant's POS should still only generate a $5 lightning invoice, not a $30 one. However, this is ultimately down to merchant's reputation to prevent them from doing so, but, because they cannot drain large amounts of money all in one go, they should not have the incentive.

The LN SERVICE should also enforce a daily maximum spend limit. If the card is lost or is stolen, the user could freeze or cancel the card from the app or the service's web portal. If there is a reasonable daily maximum limit in place, this should make it fairly secure. The user should probably also be encouraged to store the card in an NFC-blocking sleeve. The per-tap and daily limits should only apply to the card payments themselves, not to the user's funds in the wallet app. So the user could still make transactions using the app if they hit their personal-defined maximum limit for the day on the card, for example, or they could use the app to make a large $300 transaction. The limits are there for security on the card, not for preventing the user from accessing their own money.

In the UK, we already have widespread use of contactless payments with NFC-enabled Visa & Mastercard debit cards, and they have a very similar mechanism where they cannot be used for purchases of over £100. This is a global limit that is set for everybody. It was raised to £100 from £45 during the pandemic, probably to further discourage the use of physical banknotes and coins from being exchanged. Fundamentally, limits like this are needed because it is a pull technology and not a push technology. Even though 99% of the time the merchant will not request more than the payment amount, they still could, so you don't want to enable them to be able to drain your entire account.

One thing to consider is that anybody who has backend access to the LN SERVICE could potentially download all of the AES-128 secret keys for all of the users' cards and generate their own valid LNURL requests, pretending to be merchants who are charging the users' cards. The AES-128 encryption used by the card is symmetric encryption not asymmetric, so both the card and the LN SERVICE know the same secret. This means that the server-side handling of this data is something that should be very carefully thought about.

Usability and added security

A notification should probably be sent to the user's phone app whenever funds are sent using the card, which will show the amount that was sent. This would allow for immediate awareness by the user if a merchant does take too much from them. This could also help if the user is pickpocketed, as they could immediately be made aware that somebody is currently charging their card, and then they could also immediately freeze/cancel the card from the same app.

Potentially, you could also add pre-tap and post-tap authorization mechanisms. However, both of these would require the user to also have an Internet connection when paying, whereas the card by itself does not.

For pre-tap authorization, the user could use their phone or smartwatch to pre-authorize the exact amount. It could automatically round up to the next whole number and add a small buffer (say +1% for exchange rate differences), so that the user does not have to type in the exact amount. So for example, if the user is currently being charged $5.45 by a merchant, then before tapping the card to the NFC terminal they could just type $5 into their phone or smatchwatch and it would pre-authorize the next tap of the card to only allow a payment of up to $6.06 (i.e. $6 + 1%). I think that this would be best done in a separate app away from the main app, which is dedicated to just performing this function. All the app would be doing is communicating with the LN SERVICE ahead of time and letting it know what to expect on the next tap, so that it can adjust the payment limit dynamically. With a separate app, it can be given primary UI real estate for simplicity and ease of use. After the payment is sent, the card could go back to a disabled state, and the card could also timeout after two minutes if the card was never charged at all. In that context, you would have to use the phone/smartwatch app to pre-authorize a transaction, or the card wouldn't work at all. Alternatively, perhaps the user would prefer it if it just reverted back to their default per-tap spending limit. That way, it can still be used offline and would work identically as before, but if the user has an Internet connection then they can make it more secure by doing an optional pre-tap authorization step, which restricts the payment amount to be more exact.

For post-tap authorization, the user could get a notification sent to their phone or smartwatch showing the exact amount being requested by the merchant, and they would have to click on an Approve CTA for it to go through. This could be done at the final stage when the merchant sends the BOLT11 lightning invoice to the LN SERVICE. At that point, the LN SERVICE would know how much is being requested by the merchant, and the LN SERVICE could contact the customer's phone/smartwatch to get the final authorization before sending the funds. Perhaps a user would prefer to only require this authorization step when the amount being charged is above their default per-tap spending limit, so they can operate like normal but would require authorization for larger purchases. This would then allow them to lower their default limit such that most days they would not have to Approve at all, but they can still spend more if they wanted to with an extra authorization step. Alternatively, perhaps they would prefer it to always require post-tap approval for any transaction, no matter how small it is, because they believe they will always have an Internet connection and would prefer the added security.

Of course, if the user wanted to tap the merchant's NFC terminal with their NFC-enabled phone or smartwatch, instead of with a card, so that it's all integrated with their phone or smartwatch, then that is possible too. It doesn't matter how the merchant's POS device gets the LNURL-withdraw link, after all. So for example, in that case, the user might open the app on their smartwatch (perhaps requiring a PIN code or biometric approval) and then tap the POS with their smartwatch. Again, I think for something like this, it would arguably be better in a separate app away from the main app. Perhaps if it's a transaction under $30 then it just pays without the user needing to click Approve, and without the user needing to have an Internet connection in the store. If it's a $45 charge instead, then after tapping with their smartwatch, it would pop-up a request on the same smartwatch screen/app for them to have to click Approve (showing the user the $45 amount). However, of course that approval would then require the user to also have an Internet connection in the store, but that's also true in an alternative universe where the user was scanning a BOLT11 QR code and paying that way.

In this case, the user would not necessarily need a card, as their smartwatch or phone would also be capable of generating unique LNURL-withdraw links that can be verified by the LN SERVICE. In fact, the payment verification could be done even more securely than with the card, by using asymmetric encryption so that the public key on the server-side would not be as damaging to leak as the symmetric encryption key would be. The user's app may also require biometric approval or a PIN code for them to access, making it more secure if somebody pickpockets their phone/smartwatch compared to somebody pickpocketing their card. So allowing the user to set this up on their phones and smartwatches in addition to a card also seems like a natural thing to do in any case, as it would probably be a relatively easy additonal thing to support if you are already supporting the NTAG 424 DNA cards, and it could be done with an improved security profile.

Real-world examples

Below are some cool real-world examples of using the CoinCorner BOLT card:

• https://twitter.com/JoeNakamoto/status/1543253499944861696
• https://twitter.com/JoeNakamoto/status/1551567757849804800
• https://twitter.com/JosiasCarbon/status/1543504160267591680
• https://twitter.com/thinkandbemerry/status/1536294070087294979
• https://twitter.com/CoinCornerDanny/status/1553018324765884417
• https://twitter.com/CoinCornerDanny/status/1553018326498017280
• https://twitter.com/CoinCornerDanny/status/1542910770354262017
• https://twitter.com/CoinCornerDanny/status/1553023717734744064
• https://twitter.com/CoinCornerDanny/status/1553095889958354945
• https://twitter.com/BenGWeeks/status/1553066834966073344

---

† The LN SERVICE could also just remember each payment code URL that it has seen, and only allow it to be processed once. However, simply remembering the previously-seen tap counter and enforcing that it must continually increase for each payment request is a better way of achieving this. A shady merchant could program their POS device to pretend to malfunction when a user taps it, not charging them. However, it surreptitiously saves the payment code for later. Perhaps a week later they could then send the request to the LN SERVICE for the maximum possible amount. It may be difficult for the user to know or remember which merchant it was that ripped them off, and perhaps the user would have left the country by that point. However, if the LN SERVICE enforces that the tap counter must continually increase, then new requests will also invalidate any old uncharged payment codes that are currently being surreptitiously saved by merchants. This means that once the user has made a subsequent purchase with a legitimate merchant, all prior payment codes that were being saved by the shady merchant would automatically become invalid, even though they were never actually used. ↩

[titusz]

Here is a new LUD proposal for LNURL withdraw PIN support

[openoms]

Thank you @strangebit for this detailed expalanation. I have sourced some NXP NTAG 424 DNA NFC type cards and will distribute to the team for experimentation.

There are a few more resource which appeared since further supporting the self-sovereign issuance:
https://github.com/boltcard/boltcard
https://www.boltcard.org/
https://twitter.com/bolt_card

and management of the cards and the backend:
https://github.com/lnbits/lnbits/tree/main/lnbits/extensions/boltcards

The increasing adoption is tracked with the contactless badge on:
https://btcmap.org/map?lightning&nfc

[openoms]

Client side bolt card support

There are two pending PRs which would enable the mobile wallet to accept LNURLw links over NFC = client side bolt card support.

• Initial logic for lnurl-withdraw support
  Initial logic for lnurl-withdraw support blink-mobile#647
• Feature: Add NFC scanning/programming functionality
  Feature: Add NFC scanning/programming functionality blink-mobile#402

The web based NFC support like in the PoS page of BTCPayServer and the LNbits TPos could be the part of the Galoy/BBW PoS applcation.

Bolt card server

To be able to provide bolt cards backed by the individual accounts of the Galoy stack / BBW there would be two main things needed:

• Ability to generate LNURLw links - covered by this 4M sats bounty:
  Make Every Merchant a Bitcoin Vendor - 4M Sats #1418
• an implemetation of the bolt card protocol (includes https://github.com/fiatjaf/lnurl-rfc/blob/luds/17.md as described above) for which there are currently two examples:
  • https://github.com/boltcard/boltcard in Go, connects directly to the LND GRPC interface
  • https://github.com/lnbits/lnbits/tree/main/lnbits/extensions/boltcards an LNbits extension in Python