Hi Tony, > There's multiple deanonymizing techniques on LN today. Timing, CLTV, etc.
Those techniques only allow deanonymizing the recipient, not the sender? > Or you could just be a major LSP with direct routes to every node and > have end users with unannounced channels opened to you. You are aware > that with Phoenix, Acinq is aware of the sender and destination for > every outbound payment and they know the destination for every inbound? But that has nothing to do with blinded paths, and doesn't change with them? Whenever you're using a mobile wallet, you have to accept that the nodes you are connected to know that you are the sender/recipient when they forward an HTLC to/from you (because you'll never be able to hide that you're using a mobile phone and thus not relaying). And on the contrary, blinded paths will help here, because a mobile wallet using trampoline won't have to reveal the payment destination, just the blinded path introduction node. Bastien Le jeu. 27 juil. 2023 à 16:31, Tony Giorgio PM <tonygior...@protonmail.com> a écrit : > > Bastien, > > > They can't even know that they are the first hop > > There's multiple deanonymizing techniques on LN today. Timing, CLTV, etc. > > Or you could just be a major LSP with direct routes to every node and have end users with unannounced channels opened to you. You are aware that with Phoenix, Acinq is aware of the sender and destination for every outbound payment and they know the destination for every inbound? > > There's no way sphinx routing helps end users with only unannounced channels. The direct connection knows when they are the sender or receiver. So all it takes is an unannounced channel with one of the hops in the blinded route to ruin their privacy if those blinded hops are colluding. > > How it's different than today is that there's many possible routes to any given node. It's significantly more degraded with each hop added to the blinded route if those nodes participate in data sharing. And the worst part is that senders have no idea who they forward the payment down to not get caught up in that. > > I think the point is to bring awareness of this, not that we can always protect against it. Route Blinding does flip the trade offs so that receivers have great privacy and senders have worse. I think that's clear when you consider correlation attacks, unannounced channel assumptions, LSPs, and the strict enforcement of many hops being included in the blinded part of the route. > > Tony > > On 7/27/23 02:20, Bastien TEINTURIER wrote: > > Hey, > > > This breaks down since we have pretty weak anti-correlation mechanisms when a payment is being routed. With every node the recipient adds in the blinded route, there's a higher degree that a user is much closer to one of them without realizing. A sender might try to go for 6 hops, but if it turns out that their first hop is one of the nodes in the blinded route, it ruins the privacy they were trying to attain. > > I still don't see why this would expose the sender's identity? > Even if the sender is close to one of the regulated nodes, how does > that let them learn who the sender is? We're still using Sphinx, so > intermediate nodes have no way of knowing how close they are to the > sender? They can't even know that they are the first hop, and any > heuristic they'd use to try to infer that can be defeated. > > Cheers, > Bastien > > Le jeu. 27 juil. 2023 à 07:35, Tony Giorgio PM <tonygior...@protonmail.com> a écrit : >> >> Bastien, >> >> > the recipient would only provide blinded paths that go through "regulated" nodes so that they can witness the payment. >> >> Not necessarily just to witness the payment, but to ensure multiple hops away from any given payment. It's very similar to coinjoined funds. Some bitcoin custodians have implemented the concept of "multiple hops away" for on chain payments. Not all, and maybe not anymore, but I believe it was a thing. I know some moved on to "percentage of identified funds" as a risk metric. >> >> > what preserves the sender's privacy are the hops before the introduction point >> >> This breaks down since we have pretty weak anti-correlation mechanisms when a payment is being routed. With every node the recipient adds in the blinded route, there's a higher degree that a user is much closer to one of them without realizing. A sender might try to go for 6 hops, but if it turns out that their first hop is one of the nodes in the blinded route, it ruins the privacy they were trying to attain. PTLCs could help, but there's still timing and amount analysis. >> >> Tony Giorgio >> >> On 7/26/23 11:18, Bastien TEINTURIER wrote: >> >> Hey Ben, >> >> I'm not sure why it would be dramatically different from today. If I >> understand your scenario correctly, the recipient would only provide >> blinded paths that go through "regulated" nodes so that they can >> witness the payment. Since the recipient agrees on doing that, the >> recipient could simply share data with those "regulated" nodes without >> forcing payments to go through them? And they can do that today without >> blinded paths? >> >> Even if the payments go through such "regulated" nodes, what preserves >> the sender's privacy are the hops before the introduction point, that >> they can choose freely. This is exactly the same model as freely chosing >> the hops to the recipient directly (when not using blinded paths). Apart >> from the loss of potential payment routes for the recipient, it doesn't >> look like the sender's privacy is very different? >> >> Cheers, >> Bastien >> >> Le mer. 26 juil. 2023 à 16:56, Ben Carman <benthecar...@live.com> a écrit : >>> >>> Hi list, >>> >>> This is an idea I had the other week about a potential downside of blinded paths that people should be aware of. >>> >>> Blinded paths work by encrypting specific paths to reach the destination node, and each of these paths have an introduction point. >>> This has big privacy benefits for the receiving node as they can hide among an anon set of anyone within X hops of the introduction node (X being the size of the blinded path). >>> >>> However, this can have a potential downside for privacy and decentralization on the network as a whole. >>> With blinded paths since you do not know the destination node the only way to pay them is through one of the given paths. >>> Because of this, they can be used to enforce that "compliant" nodes are the only ways to reach a given destination. >>> >>> In my experience today you can get away with telling your compliance officer you will only open channels with people you trust, and we see this with some regulated businesses today (Cash App & River only open to sepcific peers). >>> However with blinded paths we could have a world where not only do they only open channels to specific peers but they enforce that when paying them, the payment must go through at least N "compliant" nodes first. >>> This would make it so the pleb routing nodes of today would be completely circumvented and users would be forced to route only through large regulated hubs. >>> The receiver would be hurting their payment reliability as they are removing potential paths they can receive from, but this is already the case for all blinded paths. >>> >>> This could hurt sender side privacy as well, since payment reliability rapidly falls off the more hops that are needed it is likely the sender would need to be very closely connected the introduction node or any of the nodes along the blinded path, and if all these compliant nodes are data sharing they'll be able to track a payment as it happens through the network just through basic timing analysis. >>> >>> My concern is lightning "chain analysis" companies could strong arm businesses into doing things like this under the guise of making sure you don't receieve OFAC coins. However, I am not sure if this is a "fixable" problem and just a trade off we'll have to make to get receiver privacy in lightning but wanted to put out there for people's opinions/awareness. >>> >>> Best, >>> >>> benthecarman >>> >>> _______________________________________________ >>> Lightning-dev mailing list >>> Lightning-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
