Store blinding pubkey for introduction node

[t-bast]

The blinding public key of the introduction node is necessary for onion messages.
The blinding ephemeral public keys aren't necessary for now: we only need the first one that will be sent to the introduction node.
The other nodes will derive the next blinding ephemeral keys hop by hop.

[thomash-acinq]

Counterproposal: #2025

[thomash-acinq]

I don't think we should throw the ephemeral keys away though, other schemes than onion messages may need it and it's useful to test them against reference test vectors (and I don't like throwing information away).

It's possible to test it:

eclair/eclair-core/src/test/scala/fr/acinq/eclair/crypto/SphinxSpec.scala

Line 397 in 8328a09

assert(ephKey2 === PublicKey(hex"02e105bc01a7af07074a1b0b1d9a112a1d89c6cd87cc4e2b6ba3a824731d9508bd"))

The first ephemeral key should stay in the blinded route. A blinded route is not usable without the first ephemeral key.
Can you give me example for when you would use the other ephemeral keys? No liking throwing information away is not a good reason.

[t-bast]

A blinded route is not usable without the first ephemeral key. Can you give me example for when you would use the other ephemeral keys? No liking throwing information away is not a good reason.

It's rather the other way around: can you be sure that you won't need it for a scheme that depends on route blinding?
I'm almost sure I need them for receiving payments over a blinded route with dummy hops added at the end of the route, to protect against probing without having to recompute them all on-the-fly.

[t-bast]

I kept only the ephemeral key for the introduction node in 40dc324, we can add the others later when we need them.

We do need to single out the introduction node for payment scenarios, and the nodeIds field is useful because it's what you will use when building a payment route.