Bitcoin's Lightning Network Could Be Getting a Privacy Upgrade
The Lightning Network, Bitcoin’s layer 2 scaling platform, has a privacy problem. Receiving payments, requesting refunds, and opening and closing payment channels (connections between Lightning nodes) – all raise privacy concerns for users of the payment network.
Those concerns have inspired protocol-based solutions like “Basis of Lightning Technology 12,” or simply, BOLT 12, a proposed solution that not only enhances privacy, but also introduces many other useful features. (“BOLTs” are Lightning draft proposals similar to Bitcoin improvement proposals or “BIPs.”)
Independent solutions have also sprung up – notably, lnproxy, an invoice privacy tool (invoices are simply payment requests), and LNURL, a suite of tools for enabling communication between various Lightning applications and services over the web.
So what’s a privacy-focused Bitcoiner to do, rely on the fledgling BOLT 12 specification or turn to one of these independent tools?
“The best thing about BOLT 12 and the technologies it relies on is that you won't need anything else,” Rusty Russell told CoinDesk. Russell is the lead developer of Core Lightning (CLN) at Bitcoin infrastructure firm, Blockstream. “Lightning nodes will give everyone the privacy they should have by default.”
Read more: What Is Bitcoin's Lightning Network?
What is BOLT 12?
“BOLT 12 adds a ton of functionality to Lightning invoices. It also adds privacy,” said Jack Sweeney, communications manager at LN Capital, creators of Torq – capital management software for Lightning routing nodes – in an interview with CoinDesk. “The real difference between BOLT 12 and something like lnproxy is that BOLT 12 is a protocol-based solution, whereas something like lnproxy is an application layer solution.”
BOLT 12 introduces “offers” to the Lightning Network. According to the official BOLT 12 website, “offers are a precursor to an invoice” that enable key functionality such as reusable QR codes, the ability to both send and receive payments and of course, enhanced privacy.
Reusable QR codes pave the way for use cases like recurring subscriptions and donations. Send and receive functionality can now be used for Lightning ATMs and private refunds. Finally, new features like route blinding, payer keys and Schnorr signatures will provide an extra layer of privacy.
Route blinding and receiving payments
Currently, receiving a Lightning payment means sharing private details with the sender (via an invoice). Route blinding (also called “blinded paths”) makes it possible for the sender to make that same payment to an anonymous recipient by hiding details about the route or path a payment has taken.
Lightning payments go from sender to receiver by “hopping” from one channel to the next via a series of Lighning nodes. With route blinding, each node only receives just enough information to pass the payment on to the next node until the payment reaches the recipient.
Payer keys and private refunds
How does a customer request a refund for a product or service they are unhappy with while keeping their identity private? Enter “payer keys.”
Offers in BOLT 12 generate payer keys that prove the origin of an invoice without revealing the customer’s identity. Combine that with route blinding and you get enhanced privacy during the refund process.
Schnorr signatures for on-chain transactions
BOLT 12 uses Schnorr signatures, the central component in Bitcoin’s Taproot upgrade. Schnorr signatures are a simpler and more efficient alternative to the Elliptic Curve Digital Signature Algorithm (ECDSA) signatures that are still commonly used in Bitcoin today.
When a Lightning channel is closed, the closing transaction is currently reflected as a 2-of-2 multisignature (multisig) transaction on the Bitcoin blockchain. This metadata, together with additional information and some sophisticated sleuthing, can ultimately expose the personal financial data of private users.
Schnorr signatures could potentially solve this issue by making Lightning transactions look like regular single-signature Bitcoin transactions via a signature scheme called MuSig2.
An anonymous developer has been quietly working on lnproxy, and although the project is new and limited in scope, it’s been gaining a few fans among Bitcoiners.
The tool uses a feature called “wrapped” invoices to hide the destination of a Lightning payment or conceal the identity of a sender’s public Lightning node. Essentially, wrapped invoices do for lnproxy, what route blinding and payer keys do for BOLT 12.
Wrapped invoices are really just “hold” (or “hodl”) invoices – payment requests that require the recipient to perform some action before cashing the payment.
Per the lnproxy website, “lnproxy takes a Bolt 11 invoice and generates a ‘wrapped’ invoice that can be settled if and only if the original invoice is settled [first].”
BOLT 12 vs. lnproxy
CLN still considers BOLT 12 experimental, and not all Lightning implementations have adopted it.
“The thing about the way Lightning spec implementation works is that you need two implementations for it to be considered fully ratified,” Sweeney explains.
Based on responses in the BOLT 12 Telegram group, several teams like Lightning wallet firm ACINQ, open-source wallet project Lightning Development Kit (LDK), and open-source Lightning implementation project Lightning Network Daemon (LND) are all working on incorporating the specification, but none has fully adopted it.
“It's essentially in beta on Core Lightning,” Sweeney says.
Lnproxy also seems to be in some sort of beta stage, based on nascency alone, although nothing on its site explicitly mentions that. Nevertheless, it’s not as fully featured as BOLT 12.
“The privacy aspect [of BOLT 12] is just one part of it. The other part of it is the ability to pay with a static invoice,” says Henrik Skogstrom, CEO and founder of LN Capital.
An alternative to lnproxy in that regard may be something like LNURL which, although comparable to BOLT 12, requires a complex setup.
LNURL is an independent project that’s developed a set of tools for enabling communication (over the web) between various Lightning applications.
Much like BOLT 12’s offers, LNURL enables withdrawals and reusable QR codes. LNURL can also replace standard username/password login schemes with a unique wallet-generated Bitcoin key, something not currently available via BOLT 12. Conversely, LNURL lacks standard BOLD 12 enhancements like blinded paths and payer keys.
But LNURL’s major drawback is that its users must run their own web server. This means setting up things like dedicated machines, software, domain names and web certificates – a process that requires time, money and expertise.
As it stands, both lnproxy and LNURL are effective additions to the Lightning “toolbox.” But the general sentiment seems to indicate little need for either, once BOLT 12 is fully adopted.
“The lnproxy server can hide your payment from the payer, but the server still knows who you paid and can definitely reveal it later. LNURL provides a nice way to request invoices but requires that you run a web service, which is not a simple thing to do,” Russell explains. “Lnproxy is a wonderful development and so is LNURL. But these are not substitutes for native Lightning privacy.”