Require using deterministic secret derivation

For simplicity's sake, we require using the deterministic derivation
scheme whenever creating a `contact_secret`. This removes most edge
cases and simplifies cross-compatibility, providing a better UX.

Author: t-bast

blip-0042.md

@@ -170,11 +170,12 @@ deal with each of them, along with a recommended UX.
 
 When Alice wants to pay Bob, her wallet should offer an option to add him to
 her contacts list (using a checkbox or a dedicated button). If she chooses
-that option, she generates a random `contact_secret`. For all future payments
-made to Bob where she wants to reveal that she's the payer, Alice will include
-this same `contact_secret`. Wallets should always offer the option to pay a
-contact privately, in which case the `contact_secret` and payer information
-will not be included in the `invoice_request`.
+that option, she generates a `contact_secret` (see details about generation
+in the [deterministic derivation section](#deterministic-derivation)). For
+all future payments made to Bob where she wants to reveal that she's the
+payer, Alice will include this `contact_secret`. Wallets should always offer
+the option to pay a contact privately, in which case the `contact_secret`
+and payer information will not be included in the `invoice_request`.
 
 Once Bob has received a payment that includes a `contact_secret`, his wallet
 should display an option to add the payer to its own contacts list (e.g. via
@@ -191,9 +192,9 @@ payments.
 However, if Bob adds Alice to his contacts list without using the payment he
 received from her, or if he adds her to his contacts list on another wallet
 than the one used to receive Alice's payment, Bob will generate a different
-random `contact_secret`. For all payments made to Alice where he wants to
-reveal that he's the payer, he will use that new `contact_secret`. When Alice
-receives those payments, she won't be able to automatically identify that it's
+`contact_secret`. For all payments made to Alice where he wants to reveal that
+he's the payer, he will use that new `contact_secret`. When Alice receives
+those payments, she won't be able to automatically identify that it's
 coming from Bob based on the `contact_secret` alone, because it is different
 from the one she generated. But if Alice knows that a specific payment came
 from Bob (because he verifiably told her so), her wallet should allow her to
@@ -224,8 +225,8 @@ haven't, they have no reason to create a new contact based on this payment.
 
 ### Deterministic derivation
 
-When creating a new contact, we recommend using the following deterministic
-derivation for the `contact_secret` field:
+When creating a new contact, we use the following deterministic derivation
+for the `contact_secret` field:
 
 - For a given Bolt 12 offer, we define its `offer_node_id` as:
   - If the offer contains `offer_issuer_id`: