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
