blog

Introduction

https://lnurl-pay.me is an unidirectional Bitcoin Lightning to fiat exchange, paying out with local Russian and Ukrainian currencies and payment methods (maybe more regions will follow, but there's no such plan yet). If you have a lightning wallet and you want to pay someone who's from Ukraine or Russia, that's probably just what you need.

The back-end (and the author, and the owner) is the same as in @LnToRubBot and its old lnurl-pay generator. The bot is not going anywhere anytime soon, and will continue to serve you.

Lightning invoices are one-time, non-reusable, and subject to expiration (that's what the bot gives you for each deal, and you have 10 minutes to make a payment). Lnurl-pay codes, on the other hand, are reusable: They're just entry points for getting a new invoice from a predefined place, with some auxiliary negotiations around it.

It took a while for lnurl-pay to gain traction and support in major wallets, but it's mostly happened by now. (See awesome-lnurl).

Generation

When generating a code with lnurl-pay.me, you can either specify a precise fiat amount of payments, or leave it up to the payer's decision. In the first case, the lightning wallet will offer, during each payment, the exact amount of satoshi that is enough to be exchanged for the given fiat value. In the second case, the wallet will offer a range for the payment's value in satoshi. This latter arrangement makes it almost impossible to pay some precise amount in fiat: your wallet's opinion of the exchange rate and my backend's opinion would necessarily differ.

lnurl-pay.me offers to specify a memo for the payment. That's what the payer's lightning wallet will probably show in payment history. More precisely, if there's a user-specified memo, it will show up as “MEMO: <your text here>”; otherwise, my server will provide description according to the payment details, like “1200 rub to mobile +75551234567” or “some sats to card 2022202244445555”. For payment links coming from my domain, I hereby declare that anything prefixed with “MEMO:” is a non-authoritative user-specified comment, while anything not prefixed with “MEMO” reflects real payment details used by the backend.

Once generated, lnurl-pay codes may be shared, printed out, kept for private use, sent to a friend. A wallet, like SBW, might retain the link after first payment, so it's available for reuse (there's a flag for it in the spec, and I set it to true).

A lightning address is generated together with each lnurl-pay code. As support for addresses is rather widespread, chance are that you can use it where you can use lnurl-pay. Fiat amount is brought into it when specified, resulting in addresses like 200rub-79175555555@mobile.lnurl-pay.me. The Memo field is the only thing that is not retained in the address: you have to use lnurl-pay link for it.

Safety

My backend takes great care not to finalize a lightning payment until the reciprocal fiat payment is complete. Many things could go wrong in the payment business, however, my main principle is that it's better to refund erroneously than to be liable for other people's money. During the 2+ years of the project's operation, there indeed were a couple of cases where a user got both a refund and a payout; the opposite thing, where I held user's satoshi without paying back, has never happened.

The only realistic way to lose your payment's value is to send it to wrong, but valid, fiat destination. That is, to top-up a wrong phone or skype account due to a typo, or to be tricked into sending funds to a banking card belonging to an impostor. As far as I know it has never happened to my users, but if it would, too bad: reversing my payouts is nontrivial enough to assume it's impossible. Double-check the receiver's account before making payment. Consider this operation as irreversible as a lightning payment itself.

Fortunately it doesn't hurt too much to split up a payment and send it in small parts, checking in between that the previous part has arrived to the right person.

Privacy

Generated lnurl-pay link contains its payment details in clear text. They aren't visually prominent in LNURL1... string because of a peculiar encoding, but it is not an encryption (see this codec). Never publish a QR code or corresponding text to an audience where you'd not share your payment details as well. Setting the MEMO field suppresses showing payment detail in the wallet's history, but it's all purely visual and cosmetic: don't count on it to protect your data.

Update: now in 2022, you can generate encrypted lightning addresses and lnurl-pay links, so publishing them won't reveal your card numbers, wallets, accounts, etc., even to those who pay with them.

Perhaps the most sensitive kind of information I work with is a Visa/MC card number. There are indeed certain risks in publishing it, but it's not really considered a secret anyway, at least not in Russia or Ukraine: card numbers are routinely published for fundraising, and some small shops provide the owner's card to settle payments in p2p.

As of data logging and retention, I'm not committed to do anything special in that regard: my web server keeps some logs that might include payment details, and they're removed when they get older. Payment details are visible to my payout providers anyway. What they don't see is the Lightning half, and LN onion routing prevents even me from any reliable guesses on the payment's source.

Lnurl-pay.me will happily serve clients and wallets coming through tor network. Note that the real risk of correlated IP+payment details disclosure is not when you generate the link (in this step, everything happens in your browser, and the server gets no data), but when the wallet makes a payment. Tor-supporting wallet could help here.

Legal

Probably illegal. Feel free to go elsewhere if it's too important to you.

As of my native jurisdiction, we've got a “cryptocurrency law” (259-ФЗ) prohibiting, among other things, any spread of information that a “cryptocurrency” may be used as a payment method for goods and services. That's exactly what I do for destinations like mobile phone top-up, and the rest is probably more severe, somewhere between unauthorized entrepreneurship and unlawful banking.

I regard exercising civil disobedience on this particular point as my duty before God.

As of potential risk for payment recipients, I believe it to be exactly the same as if they got the same money from p2p card payments (which are way popular here).