Support constructing blinded path onion keys (blinded paths, onion, crypto)

Jul 21, 2023

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.
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 does.

Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
The type for the path parameter of construct_onion_keys_callback() is changed from &Vec<RouteHop> to &Path. what is the reason for this change?
When iterating over hops in our path, why do we skip the first hop in the blinded_tail of the path?
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?
In what way and why was next_hop_packet_pubkey generalized to next_hop_pubkey in this PR?