LNURL-withdrawPOS flow

blip-0015.md

@@ -0,0 +1,117 @@
+```
+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 typically asks the user to enter an amount and under the hood it creates a Lightning invoice 
+that respect the parameters returned by the server, and sends it to the service provider, which eventually pays that.
+From a high level the user-visible flow consists of:
+
+1. Scan the QR code / paste the LNURL-withdraw link into the wallet
+2. Enter the amount to receive
+3. Confirm
+
+This repo schematizes a LNURL-withdraw flow for POS, 
+which sees the interaction between the user and a POS equipped with a NFC sensor.
+
+This bLIP documents 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, compared to the flow explained above.
+
+## 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.
+Since a LNURL-withdraw link is static, it's possible for a malicious actor to save the link and use it in t=n without the owner consensus (multi-spend attack). 
+It is also possible for a malicious actor to request a higher amount of what the POS screen shows to the user (overcharge attack), since the JSON from the server contains the range the user can request (*minWithdrawable<X<maxWithdrawable*).
+While the overcharge attack could be solved by resorting to facilitators, such as the law courts, the multi-spend attack should be prevented by the prepaid card creator and the current solutions are:
+
+**Disposable links**
+**Server-side secrets (PIN/Password/Passphrase)**
+**Server-side counters associated with a specific NFC chip (NTAG 424)**
+
+**Disposable links**
+Disposable cards are widely adopted by fiat services. A user can create a card and spend the entire amount, then the app forgets the card details and it can't be used anymore. 
+This may also exist here: whenever the user spend sats using the LNURL-withdraw link, this could be "destroyed" and a new LNURL-withdraw link could be created, which "contains" the change.
+
+**Server-side secrets (PIN/Password/Passphrase)**
+It would require to add a PIN/Password/Passphrase request to the LNURL-withdraw link, so the user's server asks the POS for a secret and gives an error if no secret/incorrect secret is provided.
+Cons: if the secret is static, it could be saved by the malicious POS and used in t=n.
+
+**Server-side counters associated with a specific NFC chip (NTAG 424)**
+This kind of tags offers a great level of interaction and encryption.
+This solution would require to implement a checking system server-side so the server can check the LNURL links, add a value to a counter and interact with a private key holded in the card. If the merchant tries to use a link associated to a previous value of the counter, the server gives an error and the merchant can't withdraw the funds.
+
+However, 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 prevent or resolve this kind of attacks.
+<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/)