Bitcoin Lightning Privacy w/ Juraj Bednar

""

Bitcoin Lightning Privacy w/ Juraj Bednar

Juraj Bednar is the author of “Author of Cryptocurrencies: Hack your way to a better life” and “Cypherpunk visions and trends” You can find him on Nostr here:

npub1m2mvvpjugwdehtaskrcl7ksvdqnnhnjur9v6g9v266nss504q7mqvlr8p9

And his website with articles & podcasts: HackYourself.io

Simplified Privacy:

Thanks for coming on. I’d like to discuss Bitcoin Lightning privacy, what it’s current strengths and limitations are. For readers who are not familiar, can you give us a brief overview of how Lightning preserves privacy? Such as onion routing or keeping things off the layer 1 blockchain.

Juraj:

I think there are a few layers that need to be considered. The main difference is that lightning is much more peer to peer than any blockchain based payment system. What I mean by that is you have channels with the peers you choose and your interactions are between you and your chosen peers.

There is no global state of the network or global ledger, it’s much more localized. It is much harder to do mass surveillance in this kind of scenario, because you would need to tap into many peer relationships.

Then routing and the possibility of multi-path payments conceals information from the routing nodes. They don’t know if they are routing part of payment, the full amount, or more than is actually being sent.

Sender privacy is pretty good by default. Receiver privacy is up to the recipients – many choose to simply publish their permanent identity, but it’s also possible to receive through one time identity.

Simplified Privacy::

Yes I’m glad you brought up the receiver privacy because I keep seeing conflicting information from different sources. Some guides say lightning node invoices require an IP, clearweb domain name, or Tor onion. Are these guides wrong, and that only a public key through the routing network is revealed? Can you elaborate on the minimum lightning receiver information?

Juraj:

Yes. The nodes have to be reachable somehow through the P2P network, but they don’t need publicly accessible IP address nor an onion address, if they can do outbound connection.

Think of it this way – your phone can run a lightning node if you have a true lightning wallet such as Breez. The IP address changes all the time. Of course the peers you communicate with have to communicate with you somehow, so you need a way to communicate. If it’s clearnet, someone needs to see your IP address, but you can connect to peers over Tor.

You have a few concepts. One is channels, then you have the identity (pubkey) of the node and then data connections to the network. You have a few choices with each of them, so it’s highly dependant on how you want to use the network.

Simplified Privacy:

Ok, I understand there are a lot of options. So let’s define some concepts. There are 3 separate issues that often get confused:

Issue 1. Self-custody vs custody wallets.

Issue 2. Your own node vs a trusted node.

Issue 3. The channels and who you open them with.

Is this how you’d define it, or am I misunderstanding? So some wallets are self-custody, but you don’t control the node seeing all the transactions, such as Phoenix. In that case, you’d have no risk of theft, but the node sees whatever data you see. Is that correct?

Juraj:

Yes, you can define it like this. But also non routing nodes (I would not call them trusted) might give you privacy in some sense, for example the on chain backing comes from their coins, so you have less risk of doxxing yourself on chain. So it’s not black and white.

In many ways, you might be better off with a node with managed liquidity over Tor and not using any on chain funds directly than running your own node.

Simplified Privacy:

When you say managed liquidity, you mean self-custody with someone else’s node, such as Phoenix wallet? Why do you prefer this over running your own node?

Juraj:

I do not prefer this, there are use cases for both.

Managed liquidity means that someone uses their on chain funds to fund the channel with you. You can also use your own funds to open channel, but then you have to think about the privacy of onchain funds.

If you have a wallet like Phoenix or Breez, you can create a lightning invoice and receive funds over lightning. The wallet provider (or liquidity provider) uses their funds to open the channel to you. These are not connected to you in any way.

Simplified Privacy:

Oh I see. So with managed liquidity, you’re trading the wallet provider seeing some data, in return for completely separating the offchain activity from on-chain funds that you control.

And WITHOUT managed liquidity, someone would have to “mix” Bitcoins first on layer 1, to afterwards get privacy with layer 2 lightning? In this case, defining “privacy” as a malicious, well-funded, and motivated adversary attempting to identify the source of lightning transactions.

Juraj:

That wouldn’t identify lightning transactions themselves that easily, remember that transactions pass through channels but are off chain.

And with managed liquidity, there are also shades of gray. For example it’s true that Phoenix sees transactions because they do the routing (still trustless, but you offload this task to their node). But with Breez or some other wallets that offer managed liquidity, the routing is done in the wallet (that’s the main reason it’s a bit slower). So currently the liquidity provider would mainly see amounts, if you use only one. If you use several or open some of your own channels, you would currently see that they are sending some amount or more (because a single payment can go through multiple channels – being split). In the future, even this can be obscured, because you can send a part of the payment to yourself. But current wallets don’t do this.

SimplifiedPrivacy:

Chainanalysis has publicly stated that they can gather information on the lightning network. But some dismiss the claims as just collecting money for lying. How much info is even available to these malicious nodes in the lightning network?

Juraj:

Well, what does it mean they can gather information? Many websites gather information, such as number and capacity of public channels.

Without being specific, I would say it’s mostly marketing, but not necessarily lying. You can do some analysis, but the question is – can you trace transactions? Obviously I don’t know, but I would bet 1M sats on no.

Simplified Privacy

Alright, so let’s move towards finishing this up with 2 solid recommendations.

First for someone whose new, and looking to learn more about lightning privacy, what tools, wallets, or providers do you suggest?

And then second, for someone whose more advanced with a high threat model and technical knowledge on Linux desktop.

Juraj:

First of all, you have to ask yourself what and who are you protecting against. Because that changes the answers quite a bit. Lightning is pretty good against mass surveillance already (and remember – there are no permanent records of transactions). So are you protecting against targeted surveillance? What are the capabilities of the adversary? Do they have broad overview of the network?

To give you an example – Phoenix has wide visibility on who you are paying, but if Acinq (the operating company of Phoenix) is not your adversary, you are better off using their service, because then payments go through their node and you actually increase your privacy by using their lightning payments (they are not very good with on-chain privacy, so I suggest only use them with Lightning). if your adversary is liquidity providers / wallet authors, then using wallets such as Blixt might be a better idea – and open some channels yourself, preferably using coins coming from coinjoin. Of course, protect network-level privacy (Phoenix has Tor support by default, but you can use many wallets with Tor).

With more advanced and higher threat level, using a Lightning node through Tor (in tor-only mode) is a better idea. There are many options, the most popular are core lightning (c-lightning) and lnd. It needs some Linux expertise to make sure you don’t make a mistake and really go through Tor. But there are services that make it easier (you can use Umbrel with well set-up firewall for example).

I would say, the question about your adversary is a pretty good idea though – and not only regarding your lightning. Because most people when they think about privacy, they want a silver bullet that solves all their privacy problems. But most people don’t have the same privacy problems as highly targeted individuals.

Simplified Privacy:

Why would one “mix” layer 1 Bitcoins if the only thing the layer 1 blockchain sees is the opening and closing of channels? If lightning is really is private, isn’t the output your self-hosted node sends disconnected?

Juraj:

If it’s a private channel it is, but still you see it’s opening and closing of a channel on chain. Most people will not need to protect against it, but it’s about the threat. You might not want people to know you’re opening a channel, or you don’t care. It’s hard to make definitive statements for every person.

Simplified Privacy:

Guys, show some love to Juraj, Nostr public key:

npub1m2mvvpjugwdehtaskrcl7ksvdqnnhnjur9v6g9v266nss504q7mqvlr8p9

And his website with articles & podcasts: HackYourself.io

If you really want to learn and take your privacy to the next level, subscribe to our new content via: Nostr, Bastyon, Session, RSS, Ethereum Push.

#

[ADMIN]

Feb 6, 2024

Related Posts

Haveno: No KYC Monero

Haveno: No KYC Monero

Haveno is a peer-to-peer marketplace to buy Monero without official KYC processes.

Aug 16, 2024

Peer-to-Peer Monero Trading Groups

Peer-to-Peer Monero Trading Groups

No KYC, Peer-to-peer groups, to buy Monero or BTC

[SP]

Aug 9, 2024

Why Cryptocurrency?

Why Cryptocurrency?

Some say: Cryptocurrency is only used by drug dealers. And my reply is, But they roll up US dollars to snort cocaine, so let’s ban that first

[SP]

Aug 8, 2024

Monero is uniquely immune to the Bubble

Monero is uniquely immune to the Bubble

The collapse was triggered by Japanese yen carry trades

[SP]

Aug 6, 2024