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
