LNURL-withdrawPOS flow

blip-0015.md

@@ -0,0 +1,96 @@
+```
+bLIP: 15
+Title: LNURL-witdhrawPOS flow
+Status: Active
+Author: David Coen <[email protected]>
+Created: 2022-05-23
+License: CC0
+```
+
+## Abstract
+
+LNURL-withdraw is a bech32-encoded HTTPS query string or sub-protocol of LNURL 
+which gives the users the ability to receive funds via Lightning Network without the need of manually create an invoice.
+Users scan a QRcode or paste the LNURL-withdraw link into their wallet, 
+this queries a server and gets a JSON with some info, 
+such as the max amount the user can receive, the min amount the user can request, etc. 
+Then the wallet tipically asks the user to enter an amount and under the hood it creates a Lightning invoice and sends it to the service provider, 
+which eventually pays that.
+So the only things the users have to do are:
+
+1. Scan the QR code / paste the LNURL-withdraw link into the wallet
+2. Enter the amount to receive
+3. Confirm
+
+In this repo I schematize a LNURL-withdraw flow for POS, 
+which sees the interaction between the user and a POS equipped with a NFC sensor.
+
+This bLIP serves to document what could be a reference flow for open source implementations of POS devices able to read LNURL-withdraw links via NFC,
+for a better UX in Lightning payments powered by LNURL protocol.
+
+## Copyright
+
+This bLIP is licensed under the CC0 license.
+
+## Specification
+
+This flowchart shows the entire flow which combines the already well-known LNURL-withdraw sub-protocol with NFC-enabled POS.
+
+![LNURL-withdraw POS flowchart](https://raw.githubusercontent.com/theDavidCoen/blips/master/blip-0015/lnurl-withdrawPOS%20flowchart.jpg)
+
+The main actor of the flow here is the merchant/payee, not the payer: 
+the merchant/payee has to simply enter an amount on the POS and this will active the NFC sensor, 
+waiting to receive the LNURL-withdraw link. The payer has to transmit the LNURL-withdrawPOS link via NFC
+and doesn't need to confirm the payment on the wallet.
+
+## Motivation
+
+Payees that support this open flow help improving the UX of Lightning payments:
+a user can just pay with a NFC tag in which a LNURL-withdraw link has been stored, instead of asking the payee to create an Invoice and scanning the QRcode.
+
+With this flow the users can also make "offline" payments and this completely change the UX of a Lightning payment: 
+they could reserve a part of their funds on a LN wallet for "offline" payments in a LNURL-withdraw string, 
+so they can use it offline, for example when they are abroad and don't have a stable connection or have roaming issues. 
+They could also define sub-balances in their wallet, so once the reserved funds are ended, no other funds in their wallet is touched.
+
+![LNURL-withdraw POS offline payments](https://raw.githubusercontent.com/theDavidCoen/blips/master/blip-0015/offline%20payments%20LNURL-withdrawPOS.png)
+
+## Rationale
+
+There are security concerns in regards to LNURL-withdraw links used as prepaid Lightning cards, which are expressed [here](https://github.com/theDavidCoen/LNURL-withdrawPOS#security-concerns-in-regards-to-lnurl-withdraw-links), but this bLIP aims just to clarify how the receiving part of the flow works and to represent a guide for an open standard, so it's not its goal to highlight them.
+<br>With an open standard we can have interoperability between many different apps and services that use LNURL protocol and the client-server interaction, in a custodial or completely non-custodial way.
+<br>This way we can share a common UX, very similar to what we have with fiat prepaid/debit/credit cards.
+
+## Differencies between BOLT11 invoice, LNURL-withdraw, LNURL-pay and LNURL-withdrawPOS flows
+
+**Normal BOLT11 invoice:**
+- Payer must be online to pay
+- Payee/Merchant must be online to receive
+- Payee/Merchant doesn't need (but can) to specify an amount to receive. 
+- Payee/Merchant tipically shows a QR code or sends a textual Lightning invoice.
+
+**LNURL-pay:**
+- Payer must be online to decode the LNURL-pay link and pay
+- Payee/Merchant must be online to ask the server to create the LNURL-pay link and receive
+- Payee/Merchant doesn't need (but can) to specify an amount to receive. 
+- Payee/Merchant tipically shows a QR code or sends a textual LNURL.
+
+**LNURL-withdraw:**
+- Payer must be online to ask the server to create the LNURL link
+- Payee/Merchant must be online to decode the LNURL-withdraw link and receive
+- Payee/Merchant must specify the amount to receive (withdraw) **in the aftermath**, selecting from a range (minWithdrawable/maxWithdrawable)
+- Payee/Merchant tipically scans a QR code or requests a textual LNURL.
+
+**LNURL-withdrawPOS:**
+- Payer can be offline, its server is always online
+- Payee/Merchant must be online to decode the LNURL-withdraw link and receive
+- Payee/Merchant must specify the amount to receive (withdraw) **in advance** 
+- Payer/Merchant doesn't need to scan the QR code or request a textual LNURL, but just waits for the payer to send the LNURL-withdraw link via NFC
+
+
+## Reference Implementations
+
+* [BTCpay's LNURL NFC Support plugin by Andrew Camilleri](https://github.com/btcpayserver/btcpayserver-plugins)
+* [Coincorner's checkout system](https://www.coincorner.com/Checkout)
+* [IBEX Mercado's Point of Sale](https://www.ibexmercado.com/)
+* [Fast Bitcoins's Point of Sale](https://fastbitcoins.com/)