[META] Allow encrypted secret to be sent on LockedTransfer's metadata

[fredo]

Note: Duplicate of https://github.com/raiden-network/light-client/issues/2730

Description

An improvement to the transfer workflow is for the node to be able to send the transfer's secret ECIES encrypted to the target, so they don't need to request it from the initiator off-band, making the transfer faster, reducing the number of messages, removing the requirement for non-channel-connected nodes to be able to communicate. The drawback is that the initiator can't know the transfer failed until it expires, due to they losing the ability to chose to reveal the secret or not, which now lays with the target.

Protocol

• Metadata must be passed through mediators as is forward
  • Unknown fields must still be included in the canonicalJSON additionalHash signature in order for it to be valid, but the actual object must not be modified, including routes; they should be exclusively set by initiator, while mediators may read-only some if they need to, e.g. to get next hop in route
• 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/userId 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.
• Upon receiving a transfer, the target:
  • Should check if secret is present in metadata, and try to decrypt and parse the resulting string as a JSON.
  • If it can, it then checks secret is present, and hashes to the transfer's secrethash
  • If any of above fails (also for backwards compatibility), target can go the usual path and SecretRequest to the initiator
  • If it can decode and secret is valid, it may only have come from initiator (which was the only one who knew the secret), then target may check if the other parameters are present and validate them, specially ensuring the actual received amount is larger than the intended metadata.secret.amount. If not, they should not reveal the secret, as mediators took more than they should; If they don't validate it or still go ahead and unlock, it implies they accepted whatever amount the initiator intended, even if less was received, and initiator can mark the transfer as paid.

Acceptance criteria

• Mediators passthrough transfer's metadata as is
• Targets can try to decrypt and validate metadata.secret, if present, use that to unlock directly and skip requesting it from initiator, if possible
• Initiator may send (on by default) secret as per above, while still being ready to follow current protocol if needed for compatibility reasons

Tasks

• [ ]

[ulope]

See https://github.com/raiden-network/light-client/issues/2730#issuecomment-847734343

[fredo]

additional note:

It should also be checked if the state machine of the initiator is modeled such that it waits for the secret request. If so we need to change that it will skip this part if the secret arrives before the request happened.