From bastien at acinq.fr Fri Apr 1 07:35:50 2022 From: bastien at acinq.fr (Bastien TEINTURIER) Date: Fri, 1 Apr 2022 09:35:50 +0200 Subject: [Lightning-dev] Blinded payments and unblinding attacks Message-ID: 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: