Re: [Lightning-dev] Blinded Paths Doom Scenario
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 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 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
Re: [Lightning-dev] Blinded Paths Doom Scenario
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 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 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
Re: [Lightning-dev] Blinded Paths Doom Scenario
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 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 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
Re: [Lightning-dev] Blinded Paths Doom Scenario
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 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
Re: [Lightning-dev] Blinded Paths Doom Scenario
Hi Ben, On the technical aspects of blinding paths, in the context of CivKit (large-scale peer-to-peer electronic market system), blinded paths could be used by market board themselves to request than makers and takers are going through the lightning node associated with the board to conclude a trade escrow over Lightning. This is quite an advanced use-case, however this would enable the board to enforce "fair auction" policy during the trade execution (e.g all the takes should send a HTLC to the board lightning node and only the best-bid is forward after a delay), or confidential dealer/breaker role where the board withhold the blinded path from the offer. So I think you have an interesting use-case of blinded paths used to enforce a payment path going through a sequence of client opted-in payment path hops. Especially when coupled with attribute-based encryption and the ECC-based blinding cryptosystem could be upgraded to something more powerful where the points are committing to things like UTXOs thanks to verifiable encryption). Now, on the legal aspects of your post. Thanks to consider the following information, as information-only and and not professional advice. Ask more to your respective attorney. Coming from an European viewpoint, one has to mention the General Data Protection Regulation Act, which is in vigor in the EU since 2018 (and the core protections still apply for the UK, even after Brexit). This general framework grants strong privacy rights to the data subject (e.g a Lightning HTLC sender) on the burden of data controller and processor. Whether a Lightning routing hop qualifies as a data controller or a processor depends on the collection and retention of personal data by the hop, from my understanding. The personal data definition given by the GDPR is the following: "any information relating to an identified or identifiable natural person" and targets explicitly location data, IP address or online identifier. From my understanding, it is probable that the Lightning payment path falls under the GDPR protection of personal data. As a consequence, a Lightning HTLC sender might be entitled to the set of rights granted to a data subject: right to be informed about data collection (e.g retention, with whom it is shared), right to rectification, right to restrict processing, right to object to processing and few more and a bunch of remedies. The GDPR and other European privacy protection acts can have an extraterritorial application and they have been applied a few times on the operation of US big tech and platforms, including with cases related to OFAC compliance. From my understanding, US-based entities are required to comply with the GDPR when dealing with European personal data, and therefore requesting a Lightning HTLC sender to go through "N" compliant nodes first like you're describing might not have a ground when you're dealing with european Lightning users. Generally, under the GDPR framework, pseudonymization and encryption are regarded as good things, and it's even recommended to encrypt processed personal data of users. Privacy is recognized as a human right under EU laws, and while obviously the Alexey Pertsev / Tornado Cash case throws an uncertainty on the boundaries of this right in the era of cryptocurrencies, privacy for its own sake is rooted in European legal tradition. It should be noted California has its own version of the GDPR, called the California Consumer Privacy Act, which explicitly gives a right to opt-out of sharing their personal information. One might oppose this right to lightning "chain analysis" companies doing "dragnet" collection of data, or at the very least check-and-balance it's used for public interest and not commercial advertising. Few more states have privacy legislation, and a compliance officer would have to notice the privilege and immunities and commerce clauses of the US constitution in the application of compliance. All that said, as soon as you start to think about new regulations and fast-moving technologies like privacy protection acts and Lightning, there is a reasonable area of uncertainty, and one is wise to be conservative. As with all new technology, of course we'll see litigation in the courts during the coming decade on those subjects. Still on the ground of the current state of law of both sides of the Atlantic, I'm confident we'll see a flourishing economy of business and plebs Lightning nodes emerge in those parts of the world. Best, Antoine Le mer. 26 juil. 2023 à 15:56, Ben Carman 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
Re: [Lightning-dev] Blinded Paths Doom Scenario
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 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
[Lightning-dev] Blinded Paths Doom Scenario
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
