Initiator sends encrypted secret in metadata

[fredo]

Abstract

In order to safe the time of sending secret requests and secret reveals between target and initiator, a safe way to speed this process up is to send the secret with the LockedTransfer. To ensure the security aspects it must be ECIES encrypted with the target's public key.
It is crucial that we maintain backwards compatibility and leave it optional to send this data with the LockedTransfer. If the initiator decides not to send it (Should be set by a flag in the RaidenConfig), simply the current way of exchanging the secret proceeds. Even if the secret was sent with the payment the target should still be able to ask for the secret.
Sending the secret directly with the LockedTransfer message should be the new default.

Below there is the description taken out of #7071

• Initiator encrypts the transfer's secret and include it in metadata.secret, together with the Request parameters, in order to ensure the target will be able to decide if they should reveal it and the mediators didn't take more fees than intended
  • Initiator always knows target's public key, due to knowing their presence, which allows the pubkey to be derived from displayName signature and used for ECIES encryption
  • metadata.secret is a hex-encoded bytestring containing the encrypted version of a CanonicalJSON-serialized object
  • pseudo-code: metadata.secret = hex_encode(encryptEcies(JSON.stringify(secret_payload), target.pubkey));
  • secret_payload schema:
    • payment_identifier: string decimal encoded number up to 64bits
    • secret: hex-string 32bytes
    • amount: string decimal encoded number up to 256bits
    • expiration: block, string decimal encoded number up to 256bits
  • If the initiator needs to retain its ability to cancel the transfer by not revealing the secret at SecretRequest time, they may simply not do it, and go with the current schema.
  • Even if sending it, the initiator should still be able to keep current behavior and reveal the secret to target in case they ask and SecretRequest parameters match, ensuring backwards compatibility.