Underrated privacy tools on Lightning
We are seeing many critics about LN not being private, but mostly are coming from people that never dig deep into using LN at its fully potential, they are were just scratching the surface, using just a Phoenix wallet or maybe another one.
Did you even hear about these terms?
- Wrapped invoice
- LN proxy (web | Github)
- 0-conf channels
- just in time channels
- trusted channels
- Zaplocker
- Lightning Box
- Dunder LSP channels
Glossary: In this guide I will use different acronyms for Lightning Service Provider (LnSP) and Liquidity Service Provider (LiSP), to not have too much confusion between them. A LnSP can be also a LiSP.
For all those node runners out there, if you want to became a good "uncle Jim" for friends and family or even for local merchants, be their local good LnSP helping them with more tools and services. This could be a real game changer and a good business around your LN node, charging (valuable) fees in sats. In the future not many people will be able to run proper public LN nodes and this is how you can help them. Helping them you help yourself (and not the banksters).
Use case scenario A
Let's consider you are a small node runner, with a public (announced) LN node, for small routing, for your family and few friends. And you want to provide also some additional privacy layers for your own use of LN and for your family/friends.
So you run a public node, well connected, well maintained, with some good routes and good liquidity. Is even possible that you run it for a small shop or not, it doesn't really matter. This node could be just a "front-run node", a "public face decoy", viewed just as any routing node. Can be linked to a real identity or not, as you wish. Can be hosted at home on a Umbrel/Start9/Raspiblitz/MiniBolt/etc node machine or on a VPS with a public IP. It doesn't really matter, in the end is just a decoy node.
What "client wallets" you can use with this node (I mean connected with some private (unannounced) channels, practically using it your own private LnSP - lightning service provider):
- Zeus LN with embedded LND node
- Blixt Wallet (mobile LND node)
- another simple private LND desktop node, can be a simple PC at home with a LND node in neutrino mode (no need for full BTC node) or a cheap VPS running LND in neutrino mode. This one you can manage it from Zeus as remote node.
These self-custodial nodes are the perfect way to use with multiple LnSP and manage your own liquidity as you wish adding more privacy.
What "services" you can provide (as a LnSP) with your own public node for these "private clients" ?
1 - Just-in-time channels
Your public node can open private channels towards these "private" mobile nodes, using wrapped invoices and 0-conf channels (not broadcast the onchain tx). Are the perfect way to onboard or start with a new mobile LN node, without requiring any funds in these mobile nodes.
How does it work?
- The receiver (mobile LN node) generates an invoices on their lightning node and then sends it to the LnSP (your public node)
- The LnSP creates a wrapped invoice and returns it to the receiver
- The receiver gives the wrapped invoices to sender (can be yourself from another LN wallet or somebody else) for them to pay
- The sender pays the invoice, which goes through the LSP
- The LnSP detects the payment and opens up a 0-conf, just in time, channel to the receiver
- The LnSP then forwards the payment to the receiver using that new channel and the payment is completed
You can see more options for this API in bLIP-52 and bLIP-51, that currently is used in Zeus calls API.
How to open JiT channels?
- In Zeus follow these instructions.
- In Blixt follow these instructions.
2 - Wrapped invoices
Wrapped invoices are invoices with extra layers around them. In this instance, the LnSP will wrap an invoice generated from your node. The wrapped invoice will appear as if it is generated by the nSP.
In the LSP node must be activated the API call for:
{
"jit_bolt11": "lntb5..." #Wrapped Bolt11 invoice which can be sent to the sender for payment
}
This has two benefits:
- The end user doesn't have to expose their node's public key to senders. The LSP knows the receiver but no one else does.
- Senders can use routes to the LSP to make a payment instead of having to find a direct path to the end user.
Wrapped invoices uses the same preimage hash as the original invoice. This means that the LSP can't settle the payment without the final receiver completing the payment, so the LSP can't run away with the user's funds.
Be sure to keep ZEUS open when receiving payment as the LSP cannot settle payments on your behalf when you're offline.
3 - Lightning Address Box / Server
This could be used as a decoy LN address, not using your own private domain for a public LN address (donations, zaps, tips, public payments etc).
Sometimes you do not want to use a private domain linked to your real identity and your node in order to receive sats over LN. You can still use those private LN addresses with your own nodes in a more restricted use case (private business, family and friends payments etc) and not being necessary to publish them online. I explained more about LN address types in this guide.
Zeus is using Zaplocker method for its @zeuspay.com type of LN Addresses. Read more about it here: https://docs.zeusln.app/lightning-address/intro/. Zeus is using "on-hold invoices" for its LN Address and will forward the sats once your Zeus is online (redeem).
Blixt is using Lightning Box method for its @blixtwallet.com type of LN Address. Blixt is not using "on-hold invoices", is just forwarding the payment to your Blixt mobile node, if is online, is acting only as a trusted LN Address server. If your Blixt node is not online the payment to your LN address will be rejected, so you must keep your Blixt on "persistent mode " in order to be able to receive through your LN address. Here is a demo video how to setup a LN address in Blixt:
4 - Private payments / no onchain fingerprint
Yes, you hear it well... NO TRACE on onchain txs. A "0-conf channel" is a not broadcast tx, a channel opened with A TRUSTED PEER that is never confirmed onchain. You can practically keep it like that forever or use "lncli abandonchannel" when you want to close it. So you could transact over LN without leaving any trace onchain. If you open a well size of that channel you literally can pass through "almost infinite" sats, back and forth.
These 0-conf channels are known ONLY between your own LSP node and your mobile private node. And by using "wrapped invoices" you are not even revealing the edge nodeID destination to the payer.
5 - Good payment routes through LiSP (liquidity service provider)
Yes, many mobile users are using random public nodes to connect and open shity channels with Tor only nodes, but then they have failed payments to destinations because their peers are not good LSPs.
As a private mobile node, you do not need many channels open with random nodes. If you have only 2 max 3 channels with good LSPs (your own public node + 1 or 2 others as backup) is more than enough for your personal use for payments.
As your own LSP, with your public "decoy" node you must have good liquidity and public routes to be able to provide successful routes from these private nodes. So keep well maintained your public node.
Keep in mind: With these private mobile nodes, when you create an invoice you have 2 options:
- you will need to use route hints embedded into the invoice string / QR
- you will need to use wrapped invoice
- you can include "blinded paths" but is not working together with wrapped invoice or route hints
Use case scenario B
Let's consider you are a well known public LiSP, selling inbound channels to multiple node runners, public or private. And I am talking to you guys: @rizful_com (Megalith), LNServer, LNbig, Blocktank, @1sats (FlashSats), @Lightning_Lavka and many others out there that are private LSP (and are not well known).
These LSP could offer these services:
- private channels to mobile nodes
- JiT channels for private mobile nodes. Can be a 0-conf channel that later be converted into a full normal channel, once the user reached a certain amount of sats received.
- 0-conf channels between 2 public trusted nodes, where is needed a "shortcut route", adjusting liquidity.
- wrapped invoice for private mobile nodes
- LN proxy for general use
- good liquidity and routes for mobile users
- charging competing fees for opening inbound channels, with fair use and renewal of lease contracts
All these could make an incredible easy onboarding experience for new users onto LN.
I hope this guide will make you think and dig deeper into LN and help you create more solutions for new users. There are so many possibilities to do wonderful things with LN that many people don't even know about them. We are barely scratching the surface now.
HAPPY LIGHTNING!
