Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-01 📝 Original message: Good morning list, In the ...

📅 Original date posted:2022-04-01
📝 Original message:
Good morning list,

In the last couple of months, @thomash-acinq and I have spent a lot of time
working on route blinding for payments [1]. As you may know, route blinding
is a prerequisite for onion messages [2] and Bolt 12 offers [3].

Using route blinding to provide anonymity for onion messages is quite
simple, but it is harder to use safely for payments. The reason for that is
that the lightning network is a very heterogeneous channels network.

The parameters used to relay payments vary widely from one channel to the
other, and can dynamically vary over time: if not accounted for, this can
provide an easy fingerprint to let malicious actors guess what channels are
actually used inside a blinded route. The ideas behind these probing attacks
are described in more details in the route blinding proposals [4].

To protect against such attacks, the latest version of the route blinding
specification lets the recipient impose what parameters will be used by
intermediate blinded nodes to relay payments (instead of using the values
they advertise in their `channel_update`). The parameters that matter are:

* `fee_base_msat`
* `fee_proportional_millionths`
* `cltv_expiry_delta`
* `htlc_minimum_msat`
* `features` that impact payment relaying behavior

We'd like help from this list to figure out whether these are the only
parameters that an attacker can use to fingerprint channels, or if there
are others that we need to take into account to guarantee user privacy.

Note that these attacks only work against public channels: wallet users
relying on unannounced channels are not at risk and will more easily
benefit from route blinding.

I spent a lot of time re-working the specification PR to make it as clear
as possible: please have a look at it and let me know if I can do anything
to make it better. Don't hesitate to reach out directly with questions and
feedback. I strongly recommend to start with the high-level design doc [5],
as natural language and detailed examples will help grasp the main ideas
and subtleties of the proposal.

Cheers,
Bastien

[1] https://github.com/lightning/bolts/pull/765
[2] https://github.com/lightning/bolts/pull/759
[3] https://github.com/lightning/bolts/pull/798
[4]
https://github.com/lightning/bolts/blob/route-blinding/proposals/route-blinding.md#attacks
[5]
https://github.com/lightning/bolts/blob/route-blinding/proposals/route-blinding.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220401/6f0347cd/attachment.html>;