"Anyone" -- oops, I should have said "the sender," not "anyone."
While I respect the attempt of nostr:npub1yxp7j36cfqws7yj0hkfu2mx25308u4zua6ud22zglxp98ayhh96s8c399s to present the Lightning network as financial privacy tech
I hate it when it provides reassurance to people who have no idea what they’re doing.
Tor + opening private channels won’t help your invoices hide information about your node.
It does help if the user has ever had any public channels. Nodes with public channels publish a network string in LN gossip, and depending on how the user set up their node, it is either a tor url or their ip address. If such a user then creates an invoice, anyone can look ip that user's network string.
As a result, if you have ever had any public channels, you are at risk of exposing your ip address via your invoices unless you run your node on tor. Running on tor thus sometimes helps your invoices hide information about your node -- specifically, its ip address.
For non-public content I think two things go a long way toward that goal:
- nip17 dms
- ephemeral keys
As for public content, I don't know if it's possible to stop people from surveilling public content. I suppose you can theoretically make content that is semi-public by only using relays that require payment to read content as well as to post it, patreon style.
Not sure if such relays exist. If they do, they probably have like two users apiece, so content posted there would not really be semi public. And if any such relay became popular, an attacker could surveil all of its users by paying the fee.
I wonder if the name nostr can be retconned into an acronym:
Nostr
---------
No STR
---------
No Suppression
No Tyranny
No Restrictions
(I wish I could say No Surveillance, but unfortunately it's very easy to surveil nostr users -- even easier than e.g. twitter users)
Anyone out there that can help? nostr:nprofile1qqszrqlfgavys8g0zf8mmy79dn92ghn723wwawx49py0nqjn7jtmjagpz4mhxue69uhkummnw3ezummcw3ezuer9wchszyrhwden5te0dehhxarj9ekk7mf0qy88wumn8ghj7mn0wvhxcmmv9uynmh4h trying to use your python nec library as well.
Hi, worry it took me 3 days to get back to you, I am preparing for a workshop in Europe. Did you try testing your implementation on the NWC tester? https://supertestnet.github.io/nwc_tester/
I recommend doing it with a backend that definitely works first, like this one: https://supertestnet.github.io/bankify/
One you have seen it work with a known-working backend, try it with your backend. Inspect the code bases to see what you are doing differently from the known-working one.
Yes, silent payment addresses are like monero addresses: pseudonymous, not anonymous. For best privacy, you should make a new address -- a new pseudonym -- for every payment, otherwise your pseudonym (your address) can be profiled, and its profile can be shared/sold/grown.
Thanks Jim! Maybe you can run the proxy software too?
The reason, btw, is because even though the senders *send to* a stealth address, they can log the original silent payment address (or monero address, or bolt12 offer, or in general any reusable payment string) and (1) use that for profiling -- every time someone asks them to send money to it, it's another data point in their profile on that payment string (2) share data with other senders about times when they sent money to that payment string, that way, together, the colluding senders know more than they would know individually
No, stealth addresses do not eliminate the weakness to the profiling attack or the colluding sender attack. Monero addresses and silent payment addresses and bolt12 offers are all weak to these two attacks if reused in the mentioned contexts.
They are neat technology, but it is bad if they make people think it is generally safe to reuse them. It is not. If you use them, you should make a new silent payment address for every service you use, and if it an anonymous service (like a swap service) you should make a new one for each *payment.*
Otherwise you are subject to two attacks:
1. Profiling
A supposedly anonymous service, like a swap service, can create a hidden profile of a user based on the address they send money to. E.g. if I use it twice with the same silent payment address, they can keep a record of that and know that at time A I received $20 and at time B I received $35, because I reused the same silent payment address. Thus they create a hidden profile on me and learn *when* I use their service and *how much* I swap there day to day, which is info they should not know. Mitigating this attack requires creating a new silent payment address for each payment whenever you use an anonymous service like that.
2. The colluding sender attack
This attack also relies on address reuse. In it, two people -- Alice and Bob -- observe that Alice sent $10 to the same silent payment address that Bob sent $5 to. So together they know the same person received at least $15, which they should not know. Ideally, Alice should only know about *her* payment and Bob should only know about *his.* But if I reuse the same address, they can compare notes and learn that both of their payments went to the same person. That's a privacy leak, and to mitigate it, you must not give the same silent payment address to two different people. Make a different one for each such payment.
You can find a peel chain like this:
(1) Use a lightning explorer (e.g. 1ml.com) to find lightning nodes that frequently create both types of channels, public and unannounced channels, e.g. LSPs like Acinq and LNBig do both.
(2) Find one of the transactions where they open a public channel. This is easy to do because public channels are announced in LN gossip, including their funding transaction, so you can literally just grab it from gossip and look it up in a block explorer.
(3) The funding transaction is likely to have two outputs: a public channel and some change. Follow the change.
(4) The LSP is likely to use the same utxos for both types of channels -- they'll create channel A, keep the change, use A's change to fund channel B, keep the change, use B's change to fund channel C, etc., and occasionally add more on-chain funds when the change output gets too small.
(5) That's a peel chain, and it has an identifiable fingerprint. You can identify the change easily because it gets spent again pretty soon; whatever's not change in any of those transactions is a channel. The ones that are announced in LN gossip are public channels; the rest are unannounced channels.
I had an AI generate a TLDR:
The essay analyzes a paper on privacy attacks against the Lightning Network (LN), highlighting three key attacks:
- Peeling Attack: Identifies unannounced channels by tracking "peeling chains" of channel openings and closures. It can find unannounced channels but only if they are part of a peel chain, and it doesn't reveal balances during the channel's operation.
- Targeted Probing Attack: Guesses the internal balances of some channels by sending payment probes through them. However, within the channel, it only determines an upper bound on one party's balance, a lower bound on the other's, and was not tried on unannounced channels.
- AOH (Assume One Hop) Attack: Assumes that most payments have only one hop, guessing the sender and recipient based on this. The attack guessed correctly 56% of the time -- little better than a coinflip -- on a simulated network that is smaller than the real LN, with no unannounced channels. It is also less effective in modern LN, where rendezvous routing is common, and the sender doesn't always choose the shortest path.
The paper's assumptions, such as the prevalence of shortest-path routing, are outdated, making some attacks less relevant today.
Today I decided to analyze a paper discussing attacks against the privacy of the lightning network.
The paper is here: https://arxiv.org/pdf/2003.12470 and it is called “An Empirical Analysis of Privacy in the Lightning Network.”
It analyzes a number of attacks on LN privacy, including one I found particularly interesting, the discussion of which contains this sentence: “We thus developed a tracing heuristic, which follows the “peeling chain” initiated at the opening and closing of public channels to identify any associated private channels.” (page 6)
The Peeling Attack (page 6)
The peeling attack is designed to identify unannounced channels on the lightning network. As part of the attack (the name for which I made up), they identified all outputs on the blockchain that could feasibly be channel opening transactions on the lightning network, and then checked how those outputs were spent.
Some of them were “channel closure” transactions, confirmed by this method: they observed that the transaction sent money to a lightning node who had public channels, and they confirmed *that* by observing that the recipient *spent* the money to open a “public” channel, which showed up in the public channel graph. Since they identified channel closure transactions of a channel that was not announced on the public graph, they knew it must be an unannounced channel.
A particularly poignant sentence is this one: “Out of the 27,183 transactions we identified as representing the opening of private channels, we were able to identify both participants in 2,035 (7.5%), one participant in 21,557 (79.3%), and no participants in 3,591 (13.2%).”
By identifying many unannounced channels via their opening and closing transactions, they could get the total capacity of those channels, as well as the “final” balance of both parties when the channel closed.
What are the weaknesses of this attack? Some are: it only finds unannounced channels if they are in a peel chain, that is, a series of transactions that keep opening and closing channels using a particular utxo and its change; it does not identify unannounced channels that are not part of a peel chain; it does not get anyone’s channel balance while the channel is open, only its total channel capacity; when it identified a channel closure, it only learned the “final” balance of the two nodes, not their transaction history.
The Targeted Probing Attack (page 8)
Regarding balances, they also have an attack for guessing the internal balances of an individual announced channel, though the attack has weaknesses. The attack is discussed in section 4, page 8 of the paper. It’s similar to Rene Pickhardt’s channel probing attack, but I will dub the new method the “targeted probing attack,” as opposed to Rene’s attack, which I dub the “dragnet probing attack.”
The targeted probing attack requires identifying a channel, which they call B -> C, where B and C are lightning nodes and the arrow is the channel between them. Then the attacker must open two “attacker” channels (the dragnet method requires only one channel), one with B and another with C. Then the attacker sends a series of payment probes, such that their channel with B is always the “from” channel and their channel with C is always the “to” channel. By only having those two channels, they know the payment probe must pass through B and C.
If the payment makes it to the destination node, then they infer that the capacity of B -> C is split up in such a way that B has at least that much money on his side of the channel; then they cancel the payment and try again with a higher amount, and keep doing they reach the channel’s capacity or the payment fails. (That’s a bit simplified; they optimize the number of transactions they must try by doing a binary search, but whatever.) At that point, they infer that the internal balance of node B in the channel B -> C is just below whatever amount failed (if there was a failure), or is just the entire capacity of the channel (if there never was a failure), and the balance of C is whatever’s leftover of the capacity of the channel.
They admit that the targeted probing attack has a weakness: “[In] the case in which there is more than one intermediate channel between the two attacker nodes…the above method identifies the bottleneck balance in the entire path, rather than the balance of an individual channel.” (page 9) Consequently, B and C may have channels between them that the attackers don’t know about (e.g. unannounced channels that weren’t in a peel chain), and thus this attack does not for-sure discern the internal balance of B for a particular channel, it only finds that he has *at most* whatever amount they got through. E.g. if they got a payment of $500 through, maybe B only had $200 on his side of the B -> C channel they were probing, but he had $300 or more in another channel with C that they didn’t know about, and routed the remainder through that channel.
The AOH Attack (Assume One Hop - page 10)
The paper discusses an attack for guessing the senders and recipients in a lightning payment, in section 5, “Path Discovery,” on page 10. They describe their attack thusly: “The strategy of our…adversary is simple: they always guess that their immediate predecessor is the sender. … Similarly, they always guess that their immediate successor is the recipient.”
Their attack relies on the assumption that most nodes will try to pass their payment through the shortest possible route to the destination, and that this means most payments will actually only have one hop: “the route to the destination in LN is constructed solely by the payment sender. All clients generally aim to find the shortest path in the network, meaning the path with the lowest amount of fees.” (page 11)
They simulate this attack in section 5.1 (page 11), where they say they took “snapshots” of the lightning network’s public nodes and channels (specifically, they say their methodology for getting the snapshot is outlined in section 3.1 on page 5, and that section only mentioned public nodes and channels – unannounced ones are only discussed later, in section 3.2). Then they assigned a routing algorithm semi-randomly to each node on this network, where the algorithms were re-written versions of the routing algorithms used by LND, CLN, and Eclair. Then they pretended these nodes sent simulated payments to one another at random, and checked how often a routing node was right if a payment passed through it and it guessed that the node before it was the sender and the node after it was the recipient. They were correct 56.65% of the time.
What are the weaknesses of this attack? Well, they were *wrong* about a single hop 43.35% of the time, so that’s already pretty damaging to their case. But also, they were working on a constrained network: they completely excluded private nodes as possible senders, and it is a lot easier to guess the sender/recipient when your simulator excludes, right at the start, a huge number of nodes that could otherwise be the sender/recipient.
Forgot to finish the last part:
Moreover, the paper was released in 2021, and some of its assumptions are no longer true, particularly these two: “the route to the destination in LN is constructed solely by the payment sender [and all] clients generally aim to find the shortest path in the network.” (page 11)
Since that time, rendezvous routing has become very common: the latest versions of lnd do it via the Blinded Routes flag, CLN and Eclair do it via bolt12, and anyone with a “legacy” lightning wallet can do it via lnproxy. Thanks to rendezvous routing, there are many cases today where the sender no longer picks the shortest path to the destination; indeed, when rendezvous routing is used, he does not *know* the destination. So the attacks outlined in this paper simply wouldn’t work today in many cases, due to the assumptions being wrong.
Today I decided to analyze a paper discussing attacks against the privacy of the lightning network.
The paper is here: https://arxiv.org/pdf/2003.12470 and it is called “An Empirical Analysis of Privacy in the Lightning Network.”
It analyzes a number of attacks on LN privacy, including one I found particularly interesting, the discussion of which contains this sentence: “We thus developed a tracing heuristic, which follows the “peeling chain” initiated at the opening and closing of public channels to identify any associated private channels.” (page 6)
The Peeling Attack (page 6)
The peeling attack is designed to identify unannounced channels on the lightning network. As part of the attack (the name for which I made up), they identified all outputs on the blockchain that could feasibly be channel opening transactions on the lightning network, and then checked how those outputs were spent.
Some of them were “channel closure” transactions, confirmed by this method: they observed that the transaction sent money to a lightning node who had public channels, and they confirmed *that* by observing that the recipient *spent* the money to open a “public” channel, which showed up in the public channel graph. Since they identified channel closure transactions of a channel that was not announced on the public graph, they knew it must be an unannounced channel.
A particularly poignant sentence is this one: “Out of the 27,183 transactions we identified as representing the opening of private channels, we were able to identify both participants in 2,035 (7.5%), one participant in 21,557 (79.3%), and no participants in 3,591 (13.2%).”
By identifying many unannounced channels via their opening and closing transactions, they could get the total capacity of those channels, as well as the “final” balance of both parties when the channel closed.
What are the weaknesses of this attack? Some are: it only finds unannounced channels if they are in a peel chain, that is, a series of transactions that keep opening and closing channels using a particular utxo and its change; it does not identify unannounced channels that are not part of a peel chain; it does not get anyone’s channel balance while the channel is open, only its total channel capacity; when it identified a channel closure, it only learned the “final” balance of the two nodes, not their transaction history.
The Targeted Probing Attack (page 8)
Regarding balances, they also have an attack for guessing the internal balances of an individual announced channel, though the attack has weaknesses. The attack is discussed in section 4, page 8 of the paper. It’s similar to Rene Pickhardt’s channel probing attack, but I will dub the new method the “targeted probing attack,” as opposed to Rene’s attack, which I dub the “dragnet probing attack.”
The targeted probing attack requires identifying a channel, which they call B -> C, where B and C are lightning nodes and the arrow is the channel between them. Then the attacker must open two “attacker” channels (the dragnet method requires only one channel), one with B and another with C. Then the attacker sends a series of payment probes, such that their channel with B is always the “from” channel and their channel with C is always the “to” channel. By only having those two channels, they know the payment probe must pass through B and C.
If the payment makes it to the destination node, then they infer that the capacity of B -> C is split up in such a way that B has at least that much money on his side of the channel; then they cancel the payment and try again with a higher amount, and keep doing they reach the channel’s capacity or the payment fails. (That’s a bit simplified; they optimize the number of transactions they must try by doing a binary search, but whatever.) At that point, they infer that the internal balance of node B in the channel B -> C is just below whatever amount failed (if there was a failure), or is just the entire capacity of the channel (if there never was a failure), and the balance of C is whatever’s leftover of the capacity of the channel.
They admit that the targeted probing attack has a weakness: “[In] the case in which there is more than one intermediate channel between the two attacker nodes…the above method identifies the bottleneck balance in the entire path, rather than the balance of an individual channel.” (page 9) Consequently, B and C may have channels between them that the attackers don’t know about (e.g. unannounced channels that weren’t in a peel chain), and thus this attack does not for-sure discern the internal balance of B for a particular channel, it only finds that he has *at most* whatever amount they got through. E.g. if they got a payment of $500 through, maybe B only had $200 on his side of the B -> C channel they were probing, but he had $300 or more in another channel with C that they didn’t know about, and routed the remainder through that channel.
The AOH Attack (Assume One Hop - page 10)
The paper discusses an attack for guessing the senders and recipients in a lightning payment, in section 5, “Path Discovery,” on page 10. They describe their attack thusly: “The strategy of our…adversary is simple: they always guess that their immediate predecessor is the sender. … Similarly, they always guess that their immediate successor is the recipient.”
Their attack relies on the assumption that most nodes will try to pass their payment through the shortest possible route to the destination, and that this means most payments will actually only have one hop: “the route to the destination in LN is constructed solely by the payment sender. All clients generally aim to find the shortest path in the network, meaning the path with the lowest amount of fees.” (page 11)
They simulate this attack in section 5.1 (page 11), where they say they took “snapshots” of the lightning network’s public nodes and channels (specifically, they say their methodology for getting the snapshot is outlined in section 3.1 on page 5, and that section only mentioned public nodes and channels – unannounced ones are only discussed later, in section 3.2). Then they assigned a routing algorithm semi-randomly to each node on this network, where the algorithms were re-written versions of the routing algorithms used by LND, CLN, and Eclair. Then they pretended these nodes sent simulated payments to one another at random, and checked how often a routing node was right if a payment passed through it and it guessed that the node before it was the sender and the node after it was the recipient. They were correct 56.65% of the time.
What are the weaknesses of this attack? Well, they were *wrong* about a single hop 43.35% of the time, so that’s already pretty damaging to their case. But also, they were working on a constrained network: they completely excluded private nodes as possible senders, and it is a lot easier to guess the sender/recipient when your simulator excludes, right at the start, a huge number of nodes that could otherwise be the sender/recipient.
I also think the paper is weak for assuming that senders and recipients are always public nodes: “We use a snapshot of the Lightning Network obtained in June 2020…[The] network [has] 4791 nodes and 28997 channels. We randomly distributed the capacity between the endpoints of each channel…[and] the sender and recipient for each transaction [were] assigned randomly…” (page 6)
By assigning the sender and recipient to only the publicly known nodes, they exclude all unannounced nodes, i.e. all nodes that do not route payments, and they greatly contract the size of the graph. That makes it much easier for them to guess senders and recipients.
I haven't seen that particular paper before, thank you for sharing it. I observe that it was published 4 years ago and new privacy preserving techniques are available now. In particular, I think the paper makes assumptions that are no longer reliable. One of them is revealed in this sentence:
"This attack is possible for any source routing protocol using shortest paths or similar selection strategies." (page 2)
Thanks to the existence of rendezvous routing (as implemtented in bolt12, bolt11 Blinded Routes, and lnproxy), many source-routed payments no longer use the shortest path to the destination. Indeed, when those protocols are used, the sender does not *know* the destination.
Another unreliable assumption is revealed in this paragraph:
"Identifying [either party] reveals information about buying and selling habits to [the attacker]. While [the attacker] might not know the exact transaction value as it only sees the transaction with fees included, these fees are typically low so that the order of magnitude of the transaction value is indeed revealed." (page 5)
When this paper was published, LND supported multipath payments for over a year. So it was already unreliable to assume any given HTLC reveals the order of magnitude of the total value transferred in the corresponding payment, because when MPP is used, multiple in flight HTLCs may carry different parts of the payment. LND uses up to 16 shards, so one can only reasonably conclude that a given HTLC reveals something like 1/16th of the total value transferred, which is an order of magnitude different from their assumptions.
Thank you for the compliments and criticism
(1) I do not claim that phoenix lets you have channels with peers other than Acinq, but I do claim that it's possible to route payments to other people without Acinq being able to detect it. I've demonstrated the feasibility and profit-potential of doing so in this video: https://www.youtube.com/watch?v=oWBX68_2TQo
Since any user can do this without detection by Acinq, Acinq has to add a caveat to all of their assumptions about the sender of a payment: "This user is the sender, unless he is forwarding someone else's payment." <-- that means they do not know the sender
Regarding the destination, Acinq does not know that either, thanks to the existence of rendezvous routing, as demonstrated by lnproxy (for bolt11) and CLN (for bolt12). They can look up info about the pubkey in a bolt11, but since that pubkey might belong to someone other than the destination, they have to add a caveat to all of their assumptions about the destination of a payment: "This pubkey belongs to the destination, unless it is a rendezvous node." <-- that means they do not know the destination
They do know the amount sent (since they only allow one channel), though, and that is one area where you admittedly have a privacy degradation by using phoenix.
(2) "That's objectively worse ux" <-- yes, on that one aspect of UX. But there are many aspects to UX and just because monero wins on one of them does not mean it wins on all of them, or even most of them. Had my opponent thought to bring this point up, I would concede that monero has better UX than lightning in this one respect, but I would not have conceded that it has better UX than lightning "in general," for the reasons I gave in the debate.
No
But it has one thing going for it: it leverages a harder money
People wonder why I dislike monero
Well, I learned how it works
I don't know. If I had to guess, I suspect that implementation didn't eliminate the minRelayTxFee filter, just relaxed it somewhat. If that's the case, then depending on how much it relaxed it, it's probably fine.