Add 2411

Author: dunxen

_posts/2023-06-20-#2289.md

@@ -6,7 +6,7 @@ pr: 2289
 authors: [arik-so]
 components: ["channel", "sign"]
 host: vladimirfomene
-status: upcoming
+status: past
 commit:
 ---
 

_posts/2023-07-21-#2411.md

@@ -0,0 +1,31 @@
+---
+layout: pr
+date: 2023-07-21
+title: "Support constructing blinded path onion keys"
+pr: 2411
+authors: [valentinewallace]
+components: ["blinded paths", "onion", "crypto"]
+host: dunxen
+status: upcoming
+commit:
+---
+
+## Notes
+
+* In general for each hop in a route a sender wishes to construct, they need to create a shared secret, including the final node receiving the payment.
+  The sender already knows the the public keys of all the hops (it's their node IDs), and generates a random `sessionkey` (`session_priv` in LDK)
+  which is used as the ephemeral private key, `ek_1`, for the first hop in the route. Multiplying by the `secp256k1` generator point, the ephemeral public
+  key, `epk_1` is derived. ECDH is then used to compute a shared secret, `ss_1`, and iteratively continues generating ephemeral keys and shared secrets
+  using a blinding factor as described in [BOLT 4](https://github.com/lightning/bolts/blob/7f53a3e46ed59f19463447d5fa63b3e484c708a5/04-onion-routing.md?plain=1#L715).
+* Now, if the recipient of a payment provides us with a blinded path, they're essentially only giving us one unblinded introduction point/node ID (which we can find a route to)
+  and a remainder of blinded node IDs. We only need to route to the introduction node of this path (it's the only node we can see) and hops within the blinded path handle the remainder.
+  However, we still need to construct a shared secret for each of those blinded hops which we do with their blinded node IDs. This is what [PR 2411](https://github.com/lightningdevkit/rust-lightning/blob/a97f084812f04b45944193d2751c9ac6a364ab3b/lightning/src/ln/onion_utils.rs#L119) does.
+
+## Questions
+1. Did you review the PR? [Concept ACK, approach ACK, tested ACK, or NACK](https://github.com/lightningdevkit/rust-lightning/blob/master/CONTRIBUTING.md#peer-review)?
+2. The type for the `path` parameter of [`construct_onion_keys_callback()`](https://github.com/lightningdevkit/rust-lightning/blob/a97f084812f04b45944193d2751c9ac6a364ab3b/lightning/src/ln/onion_utils.rs#L107) is changed from `&Vec<RouteHop>` to `&Path`.
+   what is the reason for this change?
+3. When iterating over hops in our path, why do we skip the first hop in the `blinded_tail` of the path?
+4. This PR also adds support for parsing onion error codes originating from a blinded hop.
+   Why couldn't we parse onion error codes for hops in a blinded path before this PR?
+5. In what way and why was `next_hop_packet_pubkey` generalized to `next_hop_pubkey` in this PR?