immutableMetadata capability

[andrevmatos]

This is a proposal to implement 1st bullet point of raiden-network/light-client#2730 (raiden-network/raiden#7113) in a way which keeps clients compatible with pyRaiden 2.0 (aka Bespin) release.
This implements 2 main changes:

1. Clients should not require to be the first/next address in LockedTransfer.metadata.routes[*].route: Address[] array, and instead should be able to search themselves on this array and validate that the address after is the outgoing partner/next hop.
   • on 2.0, PC expects to always be first/next route on , i.e. it expects that the previous node has prunned this route array from all previous address up to them, and would not fail the mediation if this was not strictly the case
2. With above in place, it's possible to implement immutable metadata, i.e. passthrough exactly what was received, and the additionalHash to be calculated as the exact metadata object received, JCS-serialized.
   • on 2.0, PC hashed the metadata differently from what was serialized: the hash was over the checksummed addresses, but the serialized message was sent with the lowercased addresses. Also, additional/unknown properties in metadata were not preserved.

Spec

• A new capability is added, immutableMetadata
• New clients implementing it set it to 1, otherwise, assume the fallback value of 0 (previous, 2.0 behavior). New clients:
  • When receiving a LockedTransfer message from an immutableMetadata=0 partner (legacy), we should transform addresses in metadata before calculating the additionalHash used to verify its signature. Otherwise, additionalHash should be calculated as the keccak256 hash of the canonical JSON serialization of the unvalidated/undecoded metadata.
  • When creating an outgoing LockedTransfer to an immutableMetadata=0 partner, the additionalHash must be calculated with checksummed addresses (we may decide to serialize it either as checksummed or lowercased, the change is required only for the signed/verified hash, although if also serializing the LockedTransfer.metadata payload addresses as checksummed, we'd have the serialization compatible with both old and new approach). Otherwise, as stated above, the hash must be of exactly was sent.
  • Again, on the legacy outbound path, we must prune the route array of every address up to and including us, such that partner will be the first/next address in route. In the new behavior, route is always left unchanged.

Conclusion

With the above spec, we can implement immutable metadata passthrough in a backwards compatible way, allowing us to implement new feature which depend on it, for example, secret encrypted in metadata. Of course, those features will need all hops on a path to be on the new behavior, but if not, at least they won't get out of sync and will simply fall back to the old behavior.

[fredo]

How do we handle LC v1.0.0 which does not have immutable_metadata in capabilities but already hashes the metadata as if immutable_metadata was set to 1? How was additional_hash generated in LC 1.0.0? @andrevmatos

[andrevmatos]

This proposal is backwards compatible with LC 1.0.0. The issue with signature in the old version is that client signining or verifying it must ensure the addresses in metadata payload are checksummed, but it's no problem if they're already in the serialized version. The LC does serialize it as such, but "re-ensuring" it won't break the signature, hence this proposal should work as is with all versions.