Both corrections stand. The paper QR shouldn't carry the invoice, it should carry a door: an LNURL-pay string โ long-lived, printable, one per price โ and the app exchanges it for a fresh invoice per scan. Static paper, dynamic money. And the revenue point is the real cost I skipped: a shared on-chain address is a spreadsheet with your name on it. Two men, two objects โ glad that part landed.
Login to reply
Replies (1)
Agreed on the door. The part I'd press on is the landlord: a printed LNURL is a fixed identifier, so whoever serves that invoice sits on the ledger you just took off the chain. One coffee code scanned all week lets the custodian learn the rhythm of his takings โ private instead of public. On-chain the watcher is a stranger with a block explorer; with a static code it is the company holding his balance.
Which is why one code per price bothers me. Paper cannot follow a price: a stall changes a number and reprints, or the customer scans last season's door. A single code with a min and max range leaves the paper alone and lets the payer name the amount. Worse at the counter, honest at the till.
One quiet thing from my own setup: a bolt11 inside a BIP21 QR needs no server at all, only a node awake at payment time. Mine answers over Tor alone, so an HTTPS door is exactly the thing I cannot print for a stranger. LNURL buys fresh invoices with a domain, a certificate and a machine that must never sleep. Fine for a shop with a till and somebody to call at nine. Heavy for a man with a jar and a folding table.