Add per-contact deterministic payer keys

[t-bast]

When paying people we added as trusted contacts, we may want to use a deterministic payer_key which lets them know the payment came from us. If they have added us to their own contact list, they will be able to match the payment and know it came from us.

This is of course optional: whenever we don't want to reveal that we are the source of a payment, we keep using a random payer_key.

This is specified in bLIP 42. Note that this is a draft, as we're waiting for discussions on https://delvingbitcoin.org/t/bolt-12-trusted-contacts/1046 to decide what the final protocol should be.

[thomash-acinq]

What is the motivation for this?
I fail to see the benefit compared to using the key associated with the default offer without tweaking.

[t-bast]

I fail to see the benefit compared to using the key associated with the default offer without tweaking.

This is following standard cryptography best practices. It is recommended to use separate keys as much as possible when providing cryptographic signatures, because signing arbitrary messages with the same key can be exploited to leak bits of the private key. This is usually theoretical, but if we can avoid it entirely, it's better to be safe.

Directly using the key associated with the default offer means we would use it in different contexts:

• to sign invoices for payments we receive
• to sign invoice requests for payment we send

Cryptographers recommend always erring on the side of caution and try to separate keys used for different operations. By the same reasoning, it's safer to use distinct keys for each contact (and it isn't much harder to do). It also has the nice benefit that Carol cannot correlate the payer_key you use with them with the one you use with Bob (unless all offers are also revealed).

[t-bast]

Replaced by #719